A blockchain sharding method, a blockchain system and a cross-shard consensus method

Abstract

The application discloses a blockchain sharding method, a blockchain system and a cross-sharding consensus method. The blockchain sharding method allocates a consensus group and a sharding to be monitored to each shard by using a random number, and forms a network architecture in which the shards monitor each other. Based on the sharding system that monitors each other, the application proposes a cross-sharding consensus method. The consensus group performs cross-sharding consensus on the consensus result of the monitored shard, and compares the shards in the consensus group to nodes, so that a transaction enters execution only after passing two layers of consensus. Meanwhile, the application also allows the existence of a damaged shard, maintains normal operation of the system by replacing the shard instead of repairing the shard, enhances the fault tolerance of the system, and ensures the security and activity of the system when the sharding system is configured with a smaller sharding size.

Description

Technical Field

[0001] This invention belongs to the field of blockchain sharding technology application, and particularly relates to a blockchain sharding method, a blockchain system, and a cross-sharding consensus method. Background Technology

[0002] As a decentralized distributed system, blockchain has been widely used in various scenarios, and the sharding technology derived from it has been used to improve the throughput and scalability of blockchain.

[0003] From the perspective of shard size, while smaller shards can enhance transaction concurrency, simply configuring small shards can easily lead to the allocation of too many malicious nodes in a single shard, causing shard corruption. Therefore, existing sharding protocols typically configure large shards. Although large shards can guarantee that shards will not be corrupted, this configuration limits consensus efficiency and transaction concurrency in large-scale blockchain systems. For example, in OmniLedger, if the system can accept less than 1 / 4 of malicious nodes, each shard needs to be configured with 600 nodes to ensure shard availability, slowing down the consensus speed within the shard and reducing the number of shards in the entire system, thus reducing the transaction concurrency of large-scale sharded systems.

[0004] To address the aforementioned issues, some new sharding systems propose reducing the number of malicious nodes the system can accept, sacrificing some system security to decrease shard size. However, these approaches are not suitable for large-scale public blockchains, and some require additional hardware, limiting system versatility. Other sharding systems allow for partially corrupted shards, but still have various limitations, such as the need for network synchronization or the inability to guarantee the final validity of blocks due to the PoW consensus mechanism. Still other sharding systems sacrifice some system resilience; for example, in Pyramid, system resilience is reduced from 1 / 4 to 1 / 8, meaning the system can only accept less than 1 / 8 of malicious nodes, which reduces system security.

[0005] In summary, existing sharding systems still face the challenge of enhancing transaction concurrency without compromising system security, thereby balancing system fault resilience and security. Summary of the Invention

[0006] Based on this, the present invention proposes a blockchain sharding method, a blockchain system, and a cross-shard consensus method. Each shard is monitored by a shard group consisting of several other shards, and cross-shard consensus is performed on its consensus results. The shards monitor each other to ensure system security. The system can be configured with smaller shards, thereby improving the system's transaction concurrency.

[0007] In a first aspect, the present invention provides a blockchain sharding method, executed at the beginning of each epoch, comprising:

[0008] Generate the first random number;

[0009] Each shard determines its consensus group and the shards that need to be monitored based on the first random number. Each shard in the consensus group performs inter-shard consensus on the consensus results of the monitored shards.

[0010] Furthermore, each shard determines its consensus group based on a first random number, including:

[0011] The shard uses the first random number and the shard identifier to generate a second random number. The second random number is used as a seed input to the random generator and mapped to several shards. Several shards form a consensus group to monitor the shard.

[0012] Furthermore, the above-mentioned fragmentation method also includes:

[0013] When a shard is damaged, a first random number is used to randomly map a shard in the consensus group of this shard to replace the damaged shard. The randomly mapped shard after replacement processes the transactions of this shard and the transactions of the replaced shard.

[0014] Furthermore, a first random number is generated using a combination of VRF and VDF.

[0015] In a second aspect, the present invention provides a blockchain system including monitored shards and consensus groups, wherein the monitored shards and consensus groups are determined using the blockchain sharding method of the first aspect.

[0016] Each shard within the consensus group performs inter-shard consensus on the consensus results of the monitored shard;

[0017] A shard is monitored by a consensus group, and also belongs to a consensus group that monitors other shards.

[0018] Thirdly, the present invention provides a cross-shard consensus method, applied to the blockchain system of the second aspect, executed in a consensus group, the method comprising:

[0019] Receive the consensus results of the monitored shards;

[0020] Each shard within the group reaches an inter-shard consensus on the consensus result.

[0021] If the consensus between shards passes, a confirmation message is returned to the monitored shard, and the confirmation message is written into the block of the monitored shard. Alternatively, if the consensus between shards fails, a shard replacement is triggered.

[0022] Furthermore, if consensus is reached between shards, confirmation information is returned to the monitored shard, including:

[0023] Each segment conducts intra-segment consensus on the consensus result. When the consensus result is confirmed to be valid, the first message is broadcast within the consensus group.

[0024] When each segment receives the first number of first messages, it broadcasts the second message within the consensus group;

[0025] When each segment receives the second number of second messages, it returns an acknowledgment message to the monitored segment.

[0026] Furthermore, consensus among shards does not involve triggering shard replacement, including:

[0027] If any segment confirms that the consensus result is invalid, a third message is broadcast within the consensus group;

[0028] When each shard receives the third number of third messages, it returns an alarm message to the monitored shard, triggers shard replacement, and stops consensus on the new consensus result of the monitored shard.

[0029] Using the first random number generated by the first aspect, a shard is randomly mapped within the consensus group to replace the monitored shard. The mapped shard receives the status information and transaction information sent by the monitored shard.

[0030] Furthermore, the second aspect of the cross-shard consensus method also includes:

[0031] If no consensus result is received within the set time period, a shard replacement will be triggered.

[0032] Furthermore, triggering shard replacement when no consensus result is received within the set time period includes:

[0033] If no consensus result is received within the set time period, a third message is broadcast within the consensus group;

[0034] When each shard receives the third number of third messages, it returns an alarm message to the monitored shard, triggers shard replacement, and stops consensus on the new consensus result of the monitored shard.

[0035] Using the first random number generated by the first aspect, a shard is randomly mapped within the consensus group to replace the monitored shard. The mapped shard receives the status information and transaction information sent by the monitored shard.

[0036] Furthermore, if no consensus result is received within the set time period, each shard will broadcast a third message within the group, including:

[0037] If the fourth number of nodes in a shard does not receive a consensus result within a set time period, it will generate a third message for consensus within the shard and broadcast it within the consensus group.

[0038] Furthermore, the alarm information returned to the monitored segment includes:

[0039] The third amount of third information is aggregated and sent to the monitored segment.

[0040] Furthermore, the consensus result is the header of the transaction block.

[0041] Fourthly, the present invention provides a cross-shard consensus method, applied to the blockchain system of the second aspect, executed in the monitored shard, the method comprising:

[0042] Reach consensus on transactions and send the consensus results to the consensus group;

[0043] Receive confirmation information from the consensus group, or receive fragment replacement trigger information from the consensus group.

[0044] Furthermore, the confirmation information received from the consensus group includes:

[0045] Receive confirmation messages from each segment in the consensus group;

[0046] The confirmation information for each fragment is written into the header of the transaction block.

[0047] Furthermore, receiving the fragment replacement trigger information from the consensus group includes:

[0048] Receive alarm information from each segment in the consensus group;

[0049] Each node within the shard sends its own shard status and transaction information to the shard used to replace the mapped shard.

[0050] Furthermore, the status information and transaction information sent for this fragment include:

[0051] Send the latest status information of this fragment as determined by the consensus group, the confirmation information of the previous block, and the transaction information for which consensus has not yet been completed.

[0052] Furthermore, consensus is reached on the transactions and the consensus results are sent to the consensus group, including:

[0053] Each node proposes a micro-block, and all micro-blocks are merged into a complete transaction block through consensus:

[0054] Send the header of the transaction block to the consensus group.

[0055] Furthermore, the fourth aspect of the approach also includes:

[0056] While waiting for confirmation of the current consensus result, a new round of consensus block generation will be carried out for new transactions.

[0057] Fifthly, the present invention provides a blockchain sharding system, including a consensus group and monitored shards;

[0058] Consensus groups are used to implement the third aspect of cross-shard consensus methods, while monitored shards are used to implement the fourth aspect of cross-shard consensus methods.

[0059] In a sixth aspect, the present invention provides an electronic device, including a memory and a processor;

[0060] The memory is used to store programs;

[0061] The processor is used to execute the program to implement the various steps of the aforementioned blockchain sharding method and / or cross-shard consensus method.

[0062] In a seventh aspect, the present invention provides a readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the various steps of the aforementioned blockchain sharding method and / or cross-sharding consensus method.

[0063] Compared with existing sharding systems and consensus methods, the present invention has the following advantages:

[0064] The sharding method proposed in this invention uses random numbers to map several shards to each shard. These shards form a consensus group that monitors the monitored shard, and the shard also belongs to consensus groups that monitor other shards, forming an architecture of mutual monitoring between shards. Based on this mutually monitored sharding system, this invention proposes a cross-shard consensus method. The consensus group performs inter-shard consensus on the consensus results of the monitored shards. Each shard within the consensus group is analogous to a node, so that transactions undergo two layers of consensus before execution. Under the same network scale, the sharding system can maintain security even with smaller shard sizes (more shards), thereby improving the system's transaction concurrency and system throughput. The sharding system based on the cross-shard consensus method of this invention allows for the existence of corrupted shards. When inter-shard consensus fails, it is considered that the monitored shard is corrupted or has launched an attack, triggering shard replacement. The system is restored by replacing the corrupted shard instead of repairing it, enhancing the system's fault tolerance. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0066] Figure 1 The blockchain system framework provided in the embodiments of the present invention;

[0067] Figure 2 An implementation process of a blockchain sharding method provided in this embodiment of the invention;

[0068] Figure 3 The implementation flow of the cross-shard consensus method executed in a consensus group is provided in the embodiments of the present invention;

[0069] Figure 4 This invention provides a process for monitoring the information exchange between the shard and the consensus group during cross-shard consensus.

[0070] Figure 5 This invention provides a process for a shard to interact with its consensus group in a consensus manner.

[0071] Figure 6 Another process for consensus interaction between a shard and its consensus group is provided in an embodiment of the present invention;

[0072] Figure 7 This is a schematic diagram of fragment replacement provided in an embodiment of the present invention;

[0073] Figure 8 This is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0074] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0075] Currently, most sharding systems still employ a single-layer consensus mechanism. Transactions that pass consensus within a shard are executed, while cross-shard transactions, after passing intra-shard consensus, are sent to the target shard for processing. If system security is not a concern, increasing the number of shards on the same network scale enhances transaction concurrency. This is because more shards result in higher transaction parallel processing, and more shards also mean smaller shard sizes, which reduces communication overhead for shard consensus and speeds up the consensus process.

[0076] However, security is a critical issue with small shards. Simply configuring a large number of small shards in a large-scale network / system reduces security because nodes are randomly assigned to each shard. This randomness in blockchain systems can easily lead to individual shards being assigned more malicious nodes, causing shard corruption and thus reducing system security. Therefore, most sharding systems configure large shards to ensure system security. Some solutions reduce shard size by decreasing the number of malicious nodes the system can tolerate, at the cost of some security. However, some solutions are not practical in large-scale networks / systems. For example, RapidChain increases shard elasticity to half and sets up a synchronization network for each shard to reduce shard size, which is impractical in large-scale public blockchains. Some sharding systems configure very small shards, but this is only suitable for small networks. In real-world blockchain systems, large shards are still needed to ensure system security.

[0077] To address the various shortcomings of existing sharding systems, this invention proposes a blockchain sharding method, a blockchain system, and a cross-shard consensus method. The blockchain system based on this method allows for the existence of partially damaged shards. It proposes a mechanism whereby a consensus group conducts cross-shard consensus on the consensus results of monitored shards to ensure transaction security. Undamaged shards are used to replace damaged shards to restore normal system operation. These aspects will be described in detail in the following embodiments.

[0078] like Figure 1 As shown, this illustrates the basic framework of the blockchain system of the present invention. Based on the fact that nodes are randomly assigned to various shards during system initialization, it is impossible to predict which shards will be destroyed. Figure 1 This illustrates the main idea of ​​the present invention: each shard is monitored by several other shards, and these several shards form a consensus group to conduct inter-shard consensus on the consensus results of the shards they monitor.

[0079] It's easy to understand that the monitored shard is monitored by a consensus group composed of several other shards, and also belongs to the consensus group that monitors other shards, such as... Figure 1 In one scenario, the consensus group of shard a includes shard j, and the consensus group of shard j includes shard a. The two consensus groups also share a common shard, which explains the fact that a shard is simultaneously monitored and monitors other shards.

[0080] based on Figure 1 The system framework shown, Figure 2 This illustration shows an implementation flow of a blockchain sharding method provided by an embodiment of the present invention. This flow, which occurs at the beginning of each epoch (e.g., a day), may include:

[0081] Step S11. Generate the first random number.

[0082] Specifically, distributed random numbers can be generated, which are typically generated by methods such as VDF and VRF, or other commonly used random number generation methods. In further embodiments, a combination method can also be used to generate them. In an example, a combination of VDF and VRF is used to generate verifiable, unbiased, and unpredictable random numbers.

[0083] Step S12. Each shard determines its consensus group and the shards that need to be monitored based on the first random number. Each shard in the consensus group performs inter-shard consensus on the consensus results of the monitored shards.

[0084] Specifically, nodes are randomly assigned to various shards based on a first random number and identity verification. In order to form an architecture in which shards monitor each other, this embodiment proposes that when shards are formed, each shard uses the first random number to determine which shards should be included in each consensus group. After the mapping of the first random number, each shard can determine its own consensus group and the shards that it needs to monitor (i.e., which consensus groups this shard belongs to). The shards that make up the consensus group perform inter-shard consensus on the intra-shard consensus results of the monitored shards.

[0085] Furthermore, the shard combines the first random number with the shard identifier of the current shard to generate a second random number. The shard uses the second random number as a seed to map it to several shards, forming a consensus group for monitoring the shards.

[0086] Furthermore, this embodiment allows for the existence of corrupted shards in the sharding system. When a shard launches an attack, it can be monitored by the consensus group, such as simultaneously proposing two blocks to fork the shard chain, or a silencing attack. In this case, the replacement of the corrupted shard can be triggered. The first random number generated in step S11 is used to randomly map a shard within the consensus group of the shard to replace the corrupted shard. The mapped shard will not only process the transactions of its own shard, but also the subsequent transactions of the replaced shard. The corrupted shard stops subsequent transaction consensus until the next epoch.

[0087] See Figure 3 This illustrates an implementation flow of the cross-shard consensus method provided by an embodiment of the present invention, executed within a consensus group. The flow may include:

[0088] Step S21. Receive the consensus result of the monitored shard.

[0089] Specifically, each shard within the consensus group can receive the consensus results of the monitored shard. Here, the consensus results refer to the intra-shard consensus results of the monitored shard for producing blocks for transactions. The transactions mentioned include intra-shard transactions and cross-shard transactions.

[0090] To reduce communication overhead and improve consensus efficiency, monitored shards can send the block header as the consensus result to the consensus group.

[0091] Step S22. Each shard in the group performs inter-shard consensus on the consensus result. If the inter-shard consensus passes, an acknowledgment is returned to the monitored shard. The acknowledgment is written into the block of the monitored shard. Alternatively, if the inter-shard consensus fails, a shard replacement is triggered.

[0092] Specifically, such as Figure 4 As shown, in the case where cross-shard consensus is passed, step S22 includes:

[0093] Step S221. Each shard performs intra-shard consensus on the consensus result. When the consensus result is confirmed to be valid, the first message is generated and broadcast within the consensus group.

[0094] Specifically, each segment of the consensus group first conducts intra-segment consensus on whether the consensus result is valid. If it is determined to be valid, a first message is generated and broadcast within the consensus group so that other segments of the consensus group can receive the first message.

[0095] Step S222. When each shard receives the first amount of first information, it generates second information and broadcasts it within the consensus group.

[0096] Specifically, based on the broadcast of the first information in step S221, each segment in the consensus group can receive the first information broadcast by each other. When each segment receives the first number of first information, it generates the second information and broadcasts it within the consensus group.

[0097] Step S223. When each segment receives the second number of second messages, it returns confirmation information to the monitored segment.

[0098] Specifically, this stage is similar to step S222. Each shard in the consensus group can receive the second information broadcast by each other. Once a shard receives the second number of second messages, it can initiate consensus generation of confirmation information within the shard.

[0099] After this phase is completed, the monitored shard will receive confirmation information sent by each shard in the consensus group. The confirmation information is regarded as the "finality" of the transaction block of the monitored shard consensus. In this embodiment of the invention, a transaction block is considered to have obtained "finality" only after being confirmed by the consensus group. If it is a transaction block containing cross-shard transactions, it can only be sent to the target shard for processing the transaction after being confirmed by the consensus group.

[0100] The monitoring of monitored shards by the consensus group can be viewed as a cross-shard consensus. The shards within the consensus group are analogous to nodes. Shards within the group receive first and second messages sent by each other and then respond. This is a cross-shard consensus process identical to intra-shard consensus. That is, the conditions for generating the second and confirmation messages in steps S222 and S223 are that a shard within the consensus group receives more than a set number of messages from other shards within the group. For example, receiving a first number of first messages is considered a successful consensus round, and the second message can be generated; or, receiving a second number of second messages is considered a successful consensus round, and the confirmation message can be generated. For systems that allow malicious nodes, to ensure system security and liveness, the proportion of malicious nodes cannot exceed a certain threshold to achieve consensus in the presence of malicious nodes. Therefore, the first and second numbers can be set based on such system thresholds. In terms of examples, cross-shard consensus within a consensus group can employ the PBFT consensus mechanism. When shards are analogous to nodes, it is required that no more than 1 / 3 of the shards within the consensus group are corrupt (malicious). Correspondingly, for cross-shard consensus, each shard within the group must receive consensus votes from more than 2 / 3 of the other shards in each round of consensus for that round to be considered successful. In this case, the first and second quantities can exceed 2 / 3 of the total number of shards within the group. If the consensus group adopts other consensus mechanisms, the first and second quantities can be adjusted accordingly.

[0101] Furthermore, if cross-shard consensus fails, it will trigger the replacement of the monitored shard. In this case, step S22 includes:

[0102] Step S224. When each shard confirms that the consensus result is invalid, it broadcasts a third message within the consensus group.

[0103] Specifically, each segment of the consensus group first conducts intra-segment consensus on whether the consensus result is valid. If it is determined to be invalid, a third message is generated and broadcast within the consensus group so that other segments of the consensus group can receive the third message.

[0104] Step S225. When each shard receives the third number of third messages, it returns an alarm message to the monitored shard, triggers shard replacement, and stops consensus on the new consensus result of the monitored shard.

[0105] Specifically, similar to steps S222 and S223 above, after each shard broadcasts the third information, other shards within the consensus group begin receiving it. Once a shard receives the third number of third messages, it can generate an alarm message and send it to the monitored shard. The alarm message indicates that a shard within the consensus group has detected a possible attack and corruption by the monitored shard, triggering shard replacement and simultaneously halting consensus on subsequent results for the monitored shard. In practice, the third number can be more than half the number of shards or more than two-thirds.

[0106] Furthermore, the segments within the consensus group can also send third-party information received from other segments as alarm information to the monitored segments.

[0107] Step S226. Using the first random number generated by the first aspect, randomly map a shard within the consensus group to replace the monitored shard. The mapped shard receives the status information and transaction information sent by the monitored shard.

[0108] Specifically, a random number generated during shard configuration can be used to randomly map a shard within the consensus group for replacement. Since a shard replacement has occurred, in order to ensure that transactions do not stop processing due to shard corruption, the mapped shard will receive the status information and transaction information sent by the monitored shard, and will handle the transactions that should have been routed to the monitored shard, as well as its own transactions.

[0109] Furthermore, if the monitored shard launches a silencing attack, it is also considered a case of shard corruption, which will also trigger shard replacement. The specific replacement steps are similar to the aforementioned steps S224 to S226. The difference is that in step S224, when each shard in the consensus group does not receive a consensus result from the monitored shard within a set time, a third message is broadcast within the consensus group.

[0110] Specifically, each node in a shard within the consensus group maintains a local timer. When a fourth number (e.g., more than 2 / 3) of the nodes in a shard have not received a consensus result within a set time, they reach a consensus within their own shard and generate a third message.

[0111] The following embodiment of the invention provides another implementation process for the cross-shard consensus method, which is executed at the monitored shard. This process may include:

[0112] Step S31. Reach consensus on the transactions and send the consensus results to the consensus group.

[0113] Specifically, when a monitored shard receives a transaction, it needs to first produce a block within the shard to reach a consensus. The transactions here include intra-shard transactions and cross-shard transactions. The consensus result is then sent to the consensus group for cross-shard consensus.

[0114] Furthermore, in order to eliminate the influence of malicious leader nodes on the intra-segment consensus results, a leaderless consensus protocol can be used in the example, in which each node proposes a microblock, and all microblocks are merged into a complete transaction block through consensus.

[0115] Furthermore, to improve the system's fault resilience and ensure security and normal operation while accepting more malicious nodes, the proportion of malicious nodes within a shard can be controlled through computation to ensure that most blocks contain valid transactions. On this basis, although monitored shards may still launch attacks, such blocks can be detected by the consensus group. Detecting these attacks does not require state information, only the block header, which can effectively reduce the communication overhead of the consensus group. Therefore, monitored shards can send the block header as the consensus result to each shard in the consensus group.

[0116] Step S32. Receive confirmation information from the consensus group, or receive fragment replacement trigger information from the consensus group.

[0117] Specifically, as described in the previous embodiment, when the consensus result passes the cross-shard consensus of the consensus group, each shard of the consensus group will send confirmation information to the monitored shard. This confirmation information will be written into the header of the transaction block to prove that the block has obtained "finality". The monitored shard completes the remaining consensus process. For blocks that include cross-shard transactions, they will be routed to the target shard for transaction processing only after the confirmation information from the consensus group is written.

[0118] If the consensus result fails to pass the cross-shard consensus of the consensus group, or if the monitored shard times out of sending or the consensus group times out of receiving the consensus result, a shard replacement is triggered. As described in the previous embodiment, the monitored shard will receive a shard replacement trigger information from the consensus group. In this example, such trigger information is an alarm message sent by each shard in the consensus group.

[0119] Furthermore, upon receiving the alarm information, each node within the monitored shard sends the status and transaction information of the monitored shard to the shard being mapped for replacement. In an example, the sent status information includes the latest status information determined by the consensus group, confirmation information from the previous block, and transaction information for which intra-shard consensus has not been completed, further including transaction information where the status has been rolled back.

[0120] Furthermore, since each block proposed by a shard requires final confirmation from its consensus group, maintaining transaction consensus efficiency is essential. In this example, a pipelined consensus mechanism is used, where block generation and cross-shard consensus within the consensus group are processed in parallel. Specifically, after a shard produces a block, it awaits cross-shard consensus from the consensus group. While waiting, the shard continues to produce new blocks.

[0121] To ensure system security, embodiments of this invention incorporate additional designs to the consensus process in the event of fragment corruption. When a fragment is corrupted, its block submission consensus result is considered invalid within the consensus group. Simultaneously, new blocks generated while waiting for cross-shard consensus are also considered invalid, and the fragment state is rolled back to the previous state confirmed by the consensus group. For cross-shard transactions, a state rollback in one fragment affects other fragments, significantly reducing consensus efficiency and system security. Therefore, only cross-shard consensus passing a block achieves "finality" and processes the transaction. Cross-shard transactions are only sent to the target fragment for processing after passing cross-shard consensus. This mechanism ensures that even if a fragment's state rollback occurs, new blocks generated during the waiting period are preserved as orphaned blocks.

[0122] The foregoing embodiments of the present invention describe how shard replacement can be triggered when a monitored shard is damaged to ensure the security and activity of the system. Under this mechanism, the blockchain system based on the present invention can allow more malicious nodes to exist in the shards while maintaining the normal operation of the system and ensuring the maximum probability of system security.

[0123] Taking BFT or PBFT consensus mechanisms as an example, if less than 2 / 3 of the nodes in a shard are malicious, the shard can be considered corrupted. Certain attacks, such as replay attacks, sending invalid transactions, or data unavailability, will fail to initiate. This is because honest nodes within the shard can detect such attacks during intra-shard consensus and will not sign them, preventing intra-shard consensus from succeeding. Therefore, even with less than 2 / 3 malicious nodes, it can still be guaranteed that blocks sent to the consensus group only include valid transactions. However, shards with less than 2 / 3 malicious nodes can still launch other attacks, such as forks or silence attacks. These attacks can be detected without shard state information; therefore, monitored shards only need to send the block header to reduce communication and computational overhead.

[0124] Based on this, as long as the number of damaged shards in the consensus group does not exceed 1 / 3, even if the proportion of malicious nodes f in the monitored shard is 1 / 3≤f<2 / 3 and a fork or silencing attack occurs, the consensus group can still detect it through the block header. This is because the block header can be sent by each node in the monitored shard, and there will always be honest nodes in the monitored shard.

[0125] Furthermore, since no more than one-third of the fragments within the consensus group are damaged, when more than two-thirds of the alarm messages are generated within the consensus group, the monitored fragment can be considered damaged, thus triggering fragment replacement. This invention utilizes the fragment replacement mechanism to ensure system security. If the fragment used for replacement is also a damaged fragment, fragment replacement can still be triggered to remap other fragments for replacement.

[0126] based on Figure 1The system framework shown and the foregoing embodiments are illustrated below. The following embodiments further illustrate the cross-shard consensus method of the present invention through specific scenarios.

[0127] like Figure 5 As shown, it illustrates shard i and the consensus group C that monitors it. i A consensus-based interaction process.

[0128] Shard i generated block. h block h The headers are sent to consensus group C respectively. i Each shard of the consensus group first processes the blocks within its own shard. h In this embodiment, the intra-segment consensus is set to consider the block header to be valid. At this point, each segment, based on the intra-segment consensus result, proceeds to consensus group C. i Internal broadcast first information ( Figure 5 (The Prepare information shown) indicates that each shard in the group will receive Prepare information sent by each other.

[0129] After each shard in the group receives the first number of Prepare messages, it generates the second message. Figure 5 (The commit information shown) and in consensus group C i Internal broadcasting, similarly, allows each shard within a group to receive commit messages sent by each other.

[0130] Once each shard in the group receives the second number of commit messages, it can initiate intra-shard consensus and generate confirmation messages. Figure 5 The received Finalized information is sent to fragment i, which then adds the received Finalized information to the block. h The header indicates that the block has achieved "finality".

[0131] at the same time Figure 5 The pipeline consensus mechanism is also illustrated, with shard i waiting for consensus group C. i During the cross-shard consensus process, blocks are continuously generated, and the headers of these new blocks will be sent to consensus group C later. i Perform a similar cross-shard consensus.

[0132] like Figure 6 As shown, based on Figure 2 The sharding method shown illustrates shard i and the consensus group C that monitors it. i Another consensus interaction process.

[0133] In this embodiment, the intra-segment consensus of each fragment considers the block header invalid, that is, fragment i is considered corrupted. At this time, each fragment, based on the intra-segment consensus result, proceeds to consensus group C. i Internal broadcast third information ( Figure 6 (As shown in the Complaint information), each shard in the group will receive the Complaint information sent by each other.

[0134] After each shard in the group receives the third number of Complaint messages, it generates an alarm message. In this embodiment, the Complaint messages received by each shard are sent to the shard as alarm messages, i.e., consensus group C. i Each fragment within the i-th fragment integrates all the Complain messages it receives into a single alarm message and sends it to fragment i.

[0135] like Figure 7 As shown, shard i receives consensus group C i The alarm message from the sharding indicates that shard replacement has begun. Nodes within the shard send the state information of the previous shard that was confirmed by the consensus group (i.e., the previous state that achieved "finality"), along with transaction information that has not yet reached consensus (including transactions whose state was rolled back due to block invalidity), and the confirmation information of the previous block, to the shard l that is mapped for replacement. The mapped shard l then receives the data from consensus group C. i The shard is selected from the shards within the epoch. After receiving the above information from shard i, shard l takes over the transaction processing after shard i. Subsequent transactions will also be routed to shard l. Shard l will process its own transactions and those of shard i. Shard i will stop consensus until the next epoch begins.

[0136] In other examples, when shard i launches a silencing attack or the consensus result of a block is sent to consensus group C. i An error occurred during the process, and the block header could not be received, which will also trigger the same event. Figures 6-7 This illustrates a similar alarm message sending and fragment replacement process. For example, consider a silence attack, in consensus group C... i Each node within the node maintains a local timer for shard i, when C i If the timer of more than a set proportion of nodes in a shard times out and they do not receive the block header, the shard will reach intra-shard consensus and generate a block header as shown below. Figure 6 The Complaint information is displayed, and then the execution is performed. Figure 6 and Figure 7 The steps are shown.

[0137] The embodiments provided by this invention do not require synchronization between nodes. Generally, the set time for receiving consensus results increases as the system runs and eventually tends to stabilize.

[0138] The blockchain system provided in this application embodiment can be applied to electronic devices. Figure 8 The hardware structure block diagram of this electronic device is shown below, for reference. Figure 8 The hardware structure of an electronic device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0139] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0140] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0141] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0142] The memory stores a program, which the processor can call. The program is used to: implement the various processing flows of the aforementioned blockchain sharding method, or to implement the various processing flows of the aforementioned consensus group and / or the monitored shard in the cross-sharding consensus scheme.

[0143] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor. The program is used to: implement the various processing flows of the aforementioned blockchain sharding method, or to implement the various processing flows of the aforementioned consensus group and / or monitored shard in the cross-sharding consensus scheme.

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

[0145] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain sharding method, characterized in that, Executed at the beginning of each epoch, including: Generate the first random number; Each shard determines its consensus group and the shards that need to be monitored based on the first random number. Each shard in the consensus group performs inter-shard consensus on the consensus results of the monitored shards. Specifically, the consensus group for each shard is determined based on the first random number as follows: The shard uses the first random number and the shard identifier to generate a second random number, and uses the second random number as a seed input to a random number generator to map to several shards. The several shards form a consensus group to monitor the shard, and the consensus group performs inter-shard consensus on the consensus result of the monitored shard. The inter-shard consensus process performed by the consensus group includes: Each segment within the consensus group performs intra-segment consensus on the consensus result. When the consensus result is confirmed to be valid, the first message is broadcast within the consensus group. When each segment in the consensus group receives a first number of the first information, it broadcasts the second information within the consensus group. When each segment in the consensus group receives a second number of the second information, it returns confirmation information to the monitored segment. If the consensus between the shards fails, a shard replacement is triggered, including the following process: If any segment within the consensus group does not receive a consensus result within a set time period, it broadcasts a third message within the consensus group. When each shard in the consensus group receives the third number of third messages, it returns an alarm message to the monitored shard, triggers shard replacement, and stops the consensus on the new consensus result of the monitored shard. The first random number is used to randomly map a shard within the consensus group to replace the monitored shard. The mapped shard receives the status information and transaction information sent by the monitored shard.

2. The blockchain sharding method according to claim 1, characterized in that, The method further includes: When a shard is damaged, the first random number is used to randomly map a shard from the consensus group of the damaged shard to replace the damaged shard. The randomly mapped shard then processes the transactions of its own shard and the transactions of the damaged shard.

3. The blockchain sharding method according to claim 1, characterized in that, The first random number is generated using a combination of VRF and VDF.

4. A blockchain system, characterized in that, This includes monitored shards and consensus groups; The monitored shards and consensus groups are determined using the blockchain sharding method as described in any one of claims 1 to 3; Each shard within the consensus group performs inter-shard consensus on the consensus results of the monitored shard.

5. A cross-shard consensus method, characterized in that, Applied to the blockchain system as described in claim 4, and executed within a consensus group, including: Receive the consensus results of the monitored shards; Each shard within the consensus group performs inter-shard consensus on the consensus result; If the inter-shard consensus passes, an acknowledgment is returned to the monitored shard, and the acknowledgment is written into the block; or, if the inter-shard consensus fails, a shard replacement is triggered. The consensus group to which the monitored shard belongs is determined by the method described in any one of claims 1 to 3; If the inter-shard consensus is successful, confirmation information is returned to the monitored shard, including: Each segment within the consensus group performs intra-segment consensus on the consensus result. When the consensus result is confirmed to be valid, the first message is broadcast within the consensus group. When each segment receives a first number of the first information, it broadcasts the second information within the consensus group; when each segment receives a second number of the second information, it returns confirmation information to the monitored segment. The consensus among shards does not involve triggering shard replacement, including: If any segment within the consensus group does not receive a consensus result within a set time period, it broadcasts a third message within the consensus group. When each shard receives the third number of third messages, it returns an alarm message to the monitored shard, triggers shard replacement, and stops the consensus on the new consensus result of the monitored shard. Using the first random number generated in the blockchain sharding method as described in any one of claims 1 to 3, a shard is randomly mapped within the consensus group to replace the monitored shard, and the mapped shard receives the status information and transaction information sent by the monitored shard.

6. The cross-shard consensus method according to claim 5, characterized in that, If no consensus result is received within the set time period, each shard will broadcast a third message within the consensus group, including: If the fourth number of nodes within a shard does not receive a consensus result within a set time period, the third message is generated through consensus within the shard and broadcast within the consensus group.

7. The cross-shard consensus method according to claim 5, characterized in that, The alarm information returned to the monitored segment includes: The third amount of third information is aggregated and sent to the monitored segment.

8. The cross-shard consensus method according to claim 5, characterized in that, The consensus result is the header of the transaction block.

9. A cross-shard consensus method, characterized in that, Applied to the blockchain system as described in claim 4, during monitored shard execution, including: Reach consensus on transactions and send the consensus results to the consensus group; Receive confirmation information from the consensus group, or receive fragment replacement trigger information from the consensus group.

10. The cross-shard consensus method according to claim 9, characterized in that, Receiving confirmation information from the consensus group includes: Receive confirmation information from each fragment in the consensus group; The confirmation information for each fragment is written into the header of the transaction block.

11. The cross-shard consensus method according to claim 9, characterized in that, Receiving the fragment replacement trigger information of the consensus group includes: Receive alarm information from each segment in the consensus group; Each node within the monitored shard sends its shard status information and transaction information to the shard being mapped for replacement.

12. The cross-shard consensus method according to claim 11, characterized in that, The status information and transaction information for sending this fragment include: Send the latest status information of this fragment as determined by the consensus group, the confirmation information of the previous block, and the transaction information for which consensus has not yet been completed.

13. The cross-shard consensus method according to claim 9, characterized in that, The process of reaching consensus on transactions and sending the consensus result to the consensus group includes: Each node proposes a micro-block, and all micro-blocks are merged into a complete transaction block through consensus: Send the header of the transaction block to the consensus group.

14. The cross-shard consensus method according to claim 9, characterized in that, The method further includes: While waiting for confirmation of the current consensus result, a new round of consensus block generation will be carried out for new transactions.

15. A blockchain sharding system, characterized in that, This includes consensus groups and monitored shards; The consensus group is used to implement the cross-shard consensus method as described in any one of claims 5 to 8, and the monitored shard is used to implement the cross-shard consensus method as described in any one of claims 9 to 14.

16. An electronic device, characterized in that, Including memory and processor; The memory is used to store programs; The processor is configured to execute the program to implement the blockchain sharding method as described in any one of claims 1 to 3, and / or the cross-shard consensus method as described in any one of claims 5 to 8, and / or the cross-shard consensus method as described in any one of claims 9 to 14.

17. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the blockchain sharding method as described in any one of claims 1 to 3, and / or the cross-shard consensus method as described in any one of claims 5 to 8, and / or the cross-shard consensus method as described in any one of claims 9 to 14.

Images