A blockchain sharding method, system, and server based on local repair system code.

Abstract

The present invention discloses a blockchain sharding method, system and server based on a local repair system code. The blockchain sharding system includes k original shards and n - k coded shards. In each round of consensus, each original shard and m coded shards generated by it form a local verification group (m << n - k), and each coded shard and t original shards participating in generating the coded shard form a local recovery group (t << k). The local verification group is responsible for verifying whether a pending transaction to be verified is legal. When a single shard within the verification group is bribed, the remaining m shards can reach a consistent verification result. According to the principle of the minority obeying the majority, the verification group can still correctly verify the legality of the transaction. And when a single shard is bribed, the content stored in the bribed shard can be restored through decoding calculation by the local recovery group where the shard is located. This method establishes an association among n shards through coding technology, solving the problem that the existing sharding system is insecure and unavailable due to a single shard being bribed.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and more specifically, relates to a blockchain sharding method, system, and server based on local repair system code. Background Technology

[0002] Blockchain is a distributed ledger that enables decentralized message verification and consensus. Its data is immutable, making it a reliable means of protecting digital evidence. In traditional blockchains, all nodes verify and store the entire contents of the same block, resulting in limited scalability, difficulty in increasing throughput, and high storage pressure on nodes. Blockchain sharding schemes consist of multiple shards that reach consensus on different content in parallel and independently generate different blocks, improving scalability and reducing storage pressure. However, if a single shard is bribed, the system will become insecure and unusable.

[0003] The Chinese invention patent application published on May 25, 2021, with publication number CN112835743A and titled "Distributed Ledger Data Storage Optimization Method, Apparatus, Electronic Device and Medium", proposes to perform network sharding on the blockchain system, and to perform encoding and storage within each consensus unit composed of multiple servers to alleviate storage pressure, and to reach consensus between consensus units through the PBFT algorithm.

[0004] The Chinese invention patent application published on August 27, 2019, with publication number CN110175212A and titled "Blockchain Distributed Storage Method, Data Reading Method, Device and Storage Medium", proposes that when a certain number of blocks are reached, the blocks are divided into several data segments, and then the data segments are encoded and distributed for storage.

[0005] The Chinese invention patent application published on January 7, 2022, with publication number CN113905059A and titled "A Block Storage Method and Model for a Lightweight Blockchain in the Internet of Vehicles," proposes that after a block is generated, it is encoded using LT fountain codes. Then, the encoded blocks are randomly sent to various nodes in the network, and several encoded blocks are saved in RSU. When a transaction needs to be verified, it is verified by restoring historical blocks.

[0006] However, in existing blockchain solutions that combine encoding technologies, a transaction awaiting verification is verified by only one shard, and each shard can only verify the information within the block it stores. Therefore, these solutions all suffer from the problem that if a single shard is bribed, it will be unable to verify the legitimacy of a transaction, leading to insecurity and unavailability of the entire system. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide a blockchain sharding method, system and server based on local repair system code, so as to make the whole system secure and usable.

[0008] To achieve the aforementioned objectives, this invention provides a blockchain sharding system based on partially repaired hierarchical codes. The system is characterized in that a codeword of the partially repaired hierarchical code contains n symbol bits, divided into k original symbols and nk check symbols. Each check symbol is generated by a linear combination of several original symbols. Correspondingly, this system divides multiple servers acting as blockchain nodes into n groups, each group representing a shard. The system then contains a total of n shards, including k original shards and nk encoded shards. The block data stored in each encoded shard is generated by a linear combination of the block data stored in multiple original shards. All shards use the same BFT-type algorithm for intra-shard consensus. Furthermore, one shard is selected from these n shards as the Leader shard. The Leader node of the Leader shard is denoted as LL. LL is responsible for consensus within its own shard and also participates in the consensus process of the entire blockchain sharding system.

[0009] In each consensus round, the LL calculates the local verification groups and local recovery groups in the system based on historical block data and historical VRF random number sequences. The LL distributes several transactions to be verified to multiple local verification groups corresponding to each transaction. Each shard in the verification group verifies the transaction based on its stored blocks. When a single shard in the system is bribed, other shards in the verification group to which that shard belongs can still verify the transaction, and the system remains secure and usable. After intra-shard consensus, each shard returns the consensus result to the LL. The LL calculates the consensus results of each shard to determine the legality of the transaction to be verified. Then, the LL divides the legal transactions into k parts, packages them into k blocks, and distributes them to k original shards. Each coded shard regenerates a new VRF random number in this consensus round and broadcasts it to all other shards. After receiving the block from the LL, each original shard distributes the received block to the coded shards associated with it based on the VRF random number sequence generated in this consensus round.

[0010] When a single shard in the system is bribed, the system can recover the content stored in the bribed shard by decoding and calculating the content stored in other shards within the local recovery group where the shard belongs.

[0011] Furthermore, the present invention also provides a blockchain sharding server based on locally repaired system codes. The blockchain sharding server based on locally repaired system codes is characterized in that each server represents a node in the blockchain sharding system, and the functional modules of the server node include a VRF random number generation module, a new transaction cache distribution module, a transaction information verification module, an intra-shard consensus module, a node identity module, an aggregate signature module, a vote counting and block generation and distribution module, an encoding module, and a storage module.

[0012] The VRF random number generation module is used by each coded shard to generate a random number at the beginning of each consensus round and broadcast it to all other shards in the system.

[0013] The new transaction cache distribution module is used by the LL to determine the verifiable shards based on the storage blocks of each shard and the historical VRF random number sequence after receiving the latest transaction, and then cache the transaction in the cache area corresponding to the different shards on the LL. When there is enough transaction information in the cache area, the LL sends it to the corresponding shard for verification.

[0014] The transaction information verification module is used to determine the legality of a transaction based on the transaction information stored on-chip.

[0015] The on-chip consensus module is used to reach a consensus on the verification result among the on-chip nodes, and then the on-chip Leader node returns the verification result to LL.

[0016] The node identity module is used to help nodes determine their identity and sign, so as to ensure that all messages sent by the server in the system are signed, thereby enabling verification of the message source through signature.

[0017] The aggregated signature module is used by each shard leader node to aggregate the signatures of a sufficient number of nodes within the shard that support the message when a majority of nodes within the shard need to reach a consensus on the same message and send the consensus result to other shards.

[0018] The vote counting and block generation and distribution module is used to count the transaction verification information returned by each shard and generate k blocks based on the statistical results.

[0019] The encoding module is used to generate encoded blocks. In each consensus round, LL verifies several transactions based on historical blocks, divides the legitimate transactions into k parts, packages them into k blocks, and sends them to k original shards. Each encoded shard generates its own random number based on the VRF algorithm, and uses this random number to encode the blocks stored in this round of consensus by the original shards that participated in its generation, thus obtaining the encoded blocks to be stored by this encoded shard in this round of consensus.

[0020] The storage module is used to store the blockchain data stored by the shard where this node is located.

[0021] The storage module is built on an existing database and can be further divided into a block storage module, a transaction information storage module, and a blockchain information storage module. These modules store the corresponding blocks or coded blocks for this shard, the latest status information or account balance information of the block-related UTXOs, and historical blockchain information such as VRF history. The content stored in the transaction information storage module is related to the transaction model adopted by the system.

[0022] Furthermore, this invention provides a blockchain sharding method based on locally repaired system codes, characterized by comprising a VRF random number generation and distribution stage, a transaction splitting stage, an intra-shard consensus stage, an inter-shard voting stage, a block generation stage, a block encoding stage, and a transaction information storage stage, specifically including the following steps:

[0023] (1) At the start of each consensus round, each coded fragment generates a VRF random number, signs it, and broadcasts it to all other fragments. Any fragment can associate a coded fragment with the original fragment based on the random number sequence of all coded fragments in this round.

[0024] (2) The LL collects the transaction information to be verified and stores it in the message buffer of the corresponding segment on the LL according to the historical VRF random number sequence. When the total number of transaction information to be verified in the buffer reaches the threshold, the transaction information to be verified in the corresponding buffer is sent to each segment.

[0025] (3) The Leader node of each shard leads the nodes inside the shard to verify the transaction to be verified, and reaches a consensus on the verification result through the PBFT consensus algorithm. Then, the Leader node of each shard aggregates the signatures of the results of the nodes inside the shard and returns the consensus result and aggregated signature to LL.

[0026] (4) LL calculates the consensus results of each shard. When the number of shards that are considered legitimate for a transaction to be verified exceeds the threshold, the system determines that the transaction is legitimate. When no shard in the system is bribed, any legitimate transaction is certified as legitimate. When a single shard in the system is bribed, a legitimate transaction can still be verified as legitimate by multiple other shards in the verification group, and the system remains secure and usable.

[0027] (5) Once the system has accumulated a sufficient number of valid transactions, LL divides these valid transactions into k parts, i.e., packages them into k blocks, and sends the k blocks to the original fragments corresponding to their numbers. Each original fragment distributes the received blocks to the coded fragments it participated in generating, based on the VRF random number sequence generated in this round.

[0028] (6) Each coded fragment generates its own coded block in the consensus of this round based on the block received in this round.

[0029] (7) The original shard stores its corresponding block and the transaction information therein; the encoded shard stores the UTXO information in the block received from the original shard, and saves the encoded block, and then deletes the received block.

[0030] The transaction received in step (2) consists of four parts: a transaction header, supporting historical transactions and their block heights, the newly generated transaction k as output, and other information such as the transaction user's signature. By combining the historical transactions and their block height information with the historical VRF random number sequence, LL can determine one original fragment and multiple encoded fragments that can verify the transaction.

[0031] The system code with local repair capability used in step (6) can provide the following functions:

[0032] 1) A block stored in an original shard participates in the generation of coded blocks stored in multiple coded shards, forming a verification group with these coded shards. Therefore, when a single shard in the system is bribed, other shards in the verification group to which that shard belongs can still complete the verification of a transaction to be verified, and the system remains secure.

[0033] 2) A block stored in an encoded fragment is formed by linearly combining blocks stored in multiple original fragments. The original fragments and encoded fragments involved in encoding form a local repair group. When any fragment in the group is bribed, the block of the bribed fragment can be recovered by decoding the blocks stored in other fragments in the group.

[0034] The objective of this invention is achieved as follows:

[0035] To address the problem that bribery of a single shard in current blockchain sharding schemes can lead to system insecurity and unavailability, this invention proposes a blockchain sharding method, system, and server based on locally repaired system codes, combining encoding technology with the blockchain sharding system. This system reduces storage pressure by distributing blocks across various shards; by constructing local verification groups, when a single shard within a verification group is bribed, the remaining m shards in the group can reach a consensus verification result, and according to the majority rule, the verification group can still correctly verify the legality of the transaction; by constructing local repair groups, when a single shard within a repair group is bribed, the content stored in the bribed shard can be recovered through decoding calculations using blocks stored in other shards within the group.

[0036] Therefore, this invention proposes a blockchain sharding method, system, and server based on locally repaired system codes. Through encoding technology, each original shard and m coded shards generated by it form several local verification groups. This ensures that when a shard in the system is bribed, the remaining m shards in its verification group can reach a consensus verification result. Based on the majority rule principle, the verification group can still correctly verify the legality of the transaction, and the system remains secure and usable. Furthermore, when a single shard is bribed, the content stored in the bribed shard can be recovered through decoding calculations using the local recovery group to which that shard belongs. In summary, this patent proposes a novel and feasible blockchain sharding scheme based on locally repaired system codes. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of a blockchain sharding node structure based on a local repair system code provided in Embodiment 1 of the present invention;

[0038] Figure 2 This is a schematic diagram of the blockchain sharding method based on local repair system code provided in Embodiment 2 of the present invention;

[0039] Figure 3 This is a schematic diagram of the blockchain sharding system structure based on local repair system code provided in Embodiment 3 of the present invention. Detailed Implementation

[0040] The specific embodiments of the present invention will now be described with reference to the accompanying drawings to enable those skilled in the art to better understand the invention. It should be particularly noted that in the following description, detailed descriptions of known functions and designs that might obscure the main content of the invention will be omitted here.

[0041] To combine the scalability and low node storage pressure advantages of blockchain sharding technology, while addressing the insecurity and unavailability of existing sharding systems due to bribery of a single shard, this invention provides a blockchain sharding method, system, and server based on locally repaired system codes. This introduces encoding technology into the consensus process of the blockchain sharding system. By establishing connections between multiple shards through encoding, the system can still guarantee the reliability of transaction verification even after a single shard has been bribed. The system consists of multiple servers, each with functional modules including a VRF random number generation module, a new transaction cache distribution module, a transaction information verification module, an intra-shard consensus module, a node identity module, an aggregate signature module, a vote counting and block generation and distribution module, an encoding module, and a storage module.

[0042] The VRF random number generation module is used by each coded shard to generate a random number at the beginning of each consensus round and broadcast it to all other shards in the system.

[0043] The new transaction cache distribution module is used by the LL to determine the verifiable shards based on the storage blocks of each shard and the historical VRF random number sequence after receiving the latest transaction, and then cache the transaction in the cache area corresponding to the different shards on the LL. When there is enough transaction information in the cache area, the LL sends it to the corresponding shard for verification.

[0044] The transaction information verification module is used to determine the legality of a transaction based on the transaction information stored on-chip.

[0045] The on-chip consensus module is used to reach a consensus on the verification result among the on-chip nodes, and then the on-chip Leader node returns the verification result to LL.

[0046] The node identity module is used to help nodes determine their identity and sign, so as to ensure that all messages sent by the server in the system are signed, thereby enabling verification of the message source through signature.

[0047] The aggregated signature module is used by each shard leader node to aggregate the signatures of a sufficient number of nodes within the shard that support the message when a majority of nodes within the shard need to reach a consensus on the same message and send the consensus result to other shards.

[0048] The vote counting and block generation and distribution module is used to count the transaction verification information returned by each shard and generate k blocks based on the statistical results.

[0049] The encoding module is used to generate encoded blocks. In each consensus round, LL verifies several transactions based on historical blocks, divides the legitimate transactions into k parts, packages them into k blocks, and sends them to k original shards. Each encoded shard generates its own random number based on the VRF algorithm, and uses this random number to encode the blocks stored in this round of consensus by the original shards that participated in its generation, thus obtaining the encoded blocks to be stored by this encoded shard in this round of consensus.

[0050] The storage module is used to store the blockchain data stored by the shard where this node is located.

[0051] To better understand the above technical solutions, the following will describe the above technical solutions in detail with reference to the accompanying drawings and specific implementation methods.

[0052] Example 1

[0053] This embodiment provides a blockchain sharding method, system, and server based on local repair system codes, such as... Figure 1As shown, each server represents a node in the blockchain sharding system. The functional modules of the server node include a VRF random number generation module, a new transaction cache distribution module, a transaction information verification module, an intra-shard consensus module, a node identity module, an aggregate signature module, a vote counting and block generation and distribution module, an encoding module, and a storage module.

[0054] The VRF random number generation module is used by each coded shard to generate a random number at the beginning of each consensus round and broadcast it to all other shards in the system.

[0055] Generating VRF random numbers for a shard requires a public-private key pair and a seed. In this system, the public-private key used for generating VRF for a given shard is the public-private key of the shard's leader node, and the seed used each time is the hash of the block stored in that shard. This system ensures the verifiability, fairness, randomness, and tamper-proof nature of the random numbers, preventing malicious nodes from controlling random number generation.

[0056] The new transaction cache distribution module is used by the LL to determine the verifiable shards based on the storage blocks of each shard and the historical VRF random number sequence after receiving the latest transaction, and then cache the transaction in the cache area corresponding to the different shards on the LL. When there is enough transaction information in the cache area, the LL sends it to the corresponding shard for verification.

[0057] The system saves the VRF random number sequence generated by all coded shards in each round. Based on the VRF random number sequence generated in this round, any node, after knowing the height of the block where the transaction to be verified is located, divides the block height by the number of shards to obtain the round in which the block was generated and the original shard number of the block. LL puts the transaction information into the LL cache corresponding to different shards.

[0058] The transaction information verification module is used to determine the legality of a transaction based on the transaction information stored on-chip.

[0059] When the system adopts the UTXO transaction model, the transaction information verification module of each server queries the storage module to check whether the UTXOs consumed by the transaction are available and whether the face value of the UTXOs is sufficient to pay for the transaction. When the system adopts the Account-balance transaction model, based on the transaction information in the storage module, it queries whether there is account information for the expenditure account in this shard, and then verifies whether the account balance is sufficient to support the payment transaction.

[0060] The on-chip consensus module is used to reach a consensus on the verification result among the on-chip nodes, and then the on-chip Leader node returns the verification result to LL.

[0061] Nodes within a shard can communicate with each other. The on-shard consensus module can support a variety of on-shard consensus schemes, including but not limited to POW, POS, PBFT, etc. The default on-shard consensus scheme is PBFT.

[0062] The node identity module is used to help nodes determine their identity and sign, so as to ensure that all messages sent by the server in the system are signed, thereby facilitating the verification of the message source through signature.

[0063] The aggregated signature module is used by each shard leader node to aggregate the signatures of a sufficient number of nodes within the shard that support the message when a majority of nodes within the shard need to reach a consensus on the same message and send the consensus result to other shards. The entire merging process is irreversible; the information before merging cannot be obtained from the merged public key and signatures. Furthermore, the aggregated signature only requires one verification during verification. Aggregated signatures significantly reduce communication and verification costs while maintaining information reliability.

[0064] The vote counting, block generation, and distribution module is used to count the transaction verification information returned by each shard. If more than half of the participating shards consider a transaction to be valid, then the transaction is verified as valid. After LL verifies and determines a certain number of transactions to be valid, it divides this transaction information into k parts, packages them into k blocks, and distributes them to the k original shards.

[0065] The encoding module is used to generate encoded blocks. In each consensus round, LL verifies several transactions based on historical blocks, divides the legitimate transactions into k parts, packages them into k blocks, and sends them to k original shards. Each encoded shard generates its own random number based on the VRF algorithm, and uses this random number to encode the blocks stored in this round of consensus by the original shards that participated in its generation, thus obtaining the encoded blocks to be stored by this encoded shard in this round of consensus.

[0066] The storage module is used to store the blockchain data stored by the shard to which the node belongs. Built on an existing database, the storage module can be further divided into a block storage module, a transaction information storage module, and a blockchain information storage module. These modules store the corresponding blocks or coded blocks, the latest UTXO status information or account balance information related to the blocks, and historical blockchain information such as VRF history, respectively. The content stored in the transaction information storage module depends on the transaction model adopted by the system. When the system uses a UTXO transaction model, the transaction information storage module of the coded shard stores the UTXO status information of all original blocks associated with the coded blocks stored by that shard. When the system uses an Account-balance model, the transaction information storage module of a node stores the latest status of the accounts involved in the blocks stored by that node. When the information stored for an account by the shard to which the node belongs is no longer up-to-date, the account information is deleted, and the shard to which the node storing the latest status information of the account belongs is responsible for storing the latest balance status of that account.

[0067] Example 2

[0068] This invention provides a distributed consensus method based on system codes, characterized in that the method includes a VRF random number generation and distribution stage, a transaction splitting stage, an intra-segment consensus stage, an inter-segment voting stage, a block generation stage, a block encoding stage, and a transaction information storage stage, such as... Figure 2 As shown, the method includes the following steps:

[0069] (1) At the start of each consensus round, each coded fragment generates a VRF random number, signs it, and broadcasts it to all other fragments. Any fragment can associate a coded fragment with the original fragment based on the random number sequence of all coded fragments in this round.

[0070] (2) The LL collects the transaction information to be verified and stores it in the message buffer of the corresponding segment on the LL according to the historical VRF random number sequence. When the total number of transaction information to be verified in the buffer reaches the threshold, the transaction information to be verified in the corresponding buffer is sent to each segment.

[0071] A transaction consists of four parts: a transaction header, supporting historical transactions and their block heights, the newly generated transaction as output, and the transaction user's signature. By combining the historical transactions and their block height information with historical VRF random number sequences, LL can determine one original fragment and multiple encoded fragments that can verify the transaction. When the system uses the UTXO model, historical transactions refer to the generated transactions that serve as input to the UTXO. When the system uses the Account-balance model, historical transactions refer to the user's last transaction.

[0072] (3) The Leader node of each shard leads the nodes inside the shard to verify the transaction to be verified, and reaches a consensus on the verification result through the PBFT consensus algorithm. Then, the Leader node of each shard aggregates the signatures of the results of the nodes inside the shard and returns the consensus result and aggregated signature to LL.

[0073] (4) LL calculates the consensus results of each shard. When the number of shards that are considered legitimate for a transaction to be verified exceeds the threshold, the system determines that the transaction is legitimate. When no shard in the system is bribed, any legitimate transaction is certified as legitimate. When a single shard in the system is bribed, a legitimate transaction can still be verified as legitimate by multiple other shards in the verification group, and the system remains secure and usable.

[0074] (5) Once the system has accumulated a sufficient number of valid transactions, LL divides these valid transactions into k parts, i.e., packages them into k blocks, and sends the k blocks to the original fragments corresponding to their numbers. Each original fragment distributes the received blocks to the coded fragments it participated in generating, based on the VRF random number sequence generated in this round.

[0075] (6) Each coded fragment generates its own coded block in the consensus of this round based on the block received in this round.

[0076] (7) The original shard stores its corresponding block and the transaction information therein; the encoded shard stores the UTXO information in the block received from the original shard, and saves the encoded block, and then deletes the received block.

[0077] Example 3

[0078] This invention provides a blockchain system based on system codes, characterized in that, as Figure 3 As shown, this system divides multiple servers acting as blockchain nodes into n groups, each group representing a shard. The system contains a total of n shards, including k original shards and nk encoded shards. The block data stored in each encoded shard is generated by a linear combination of the block data stored in multiple original shards. All shards use the same BFT-like algorithm for intra-shard consensus. Furthermore, one shard is selected from these n shards as the Leader shard. The Leader node of the Leader shard is denoted as LL. LL is responsible for consensus within its own shard and participates in the consensus process of the entire blockchain sharding system. All nodes within the same shard store the same block information, while nodes in different shards store different block information. No single node stores all blocks, but all nodes must store an encoded matrix generated by VRF random numbers.

[0079] Although the illustrative specific embodiments of the present invention have been described above to enable those skilled in the art to understand the invention, it should be understood that the invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the invention as defined and determined by the appended claims, and all inventions utilizing the concept of the present invention are protected.

Claims

1. A blockchain sharding server based on local repair system code, characterized in that, A codeword in the partial repair system code contains n sign bits, which are divided into k original symbols and nk check symbols. Each check symbol is generated by a linear combination of several original symbols. The multiple servers acting as blockchain nodes are divided into n groups, each group representing a shard, resulting in a total of n shards, which are divided into k original shards and nk encoded shards. The block data stored in each encoded shard is generated by a linear combination of the block data stored in multiple original shards. All shards use the same Byzantine Fault Tolerant (BFT) algorithm for intra-shard consensus. Furthermore, one of the n shards is selected as the Leader shard, and the Leader node of the Leader shard is denoted as LL. In addition to being responsible for the consensus within its own shard, LL also participates in the consensus process of the entire blockchain sharding system. The original shard and m coded shards generated by it form several local verification groups. This ensures that when a shard in the system is bribed, the remaining m shards in its verification group can reach a consistent verification result. According to the principle of majority rule, the verification group can still correctly verify the legality of the transaction. Moreover, when a single shard is bribed, the content stored in the bribed shard can be recovered through decoding calculation by the local recovery group to which the shard belongs. Each server represents a node in the blockchain sharding system. The functional modules of the server node include a Verifiable Random Function (VRF) random number generation module, a new transaction cache distribution module, a transaction information verification module, an intra-shard consensus module, a node identity module, an aggregate signature module, a vote counting and block generation and distribution module, an encoding module, and a storage module. The VRF random number generation module is used by each coding segment to generate a random number at the beginning of each round of consensus and broadcast it to all other segments in the system. The new transaction cache distribution module is used by the LL to determine the shard that can verify the transaction after receiving the latest transaction, based on the storage blocks of each shard and the historical VRF random number sequence, and then cache the transaction in the cache area of ​​the LL corresponding to different shards. When there is enough transaction information in the cache area, the LL sends it to the corresponding shard for verification. The transaction information verification module is used to determine the legality of a transaction based on the transaction information stored on the chip. The on-chip consensus module is used to reach a consensus on the verification result among the on-chip nodes, and then the on-chip Leader node returns the verification result to LL; The node identity module is used to help nodes determine their identity and sign, so as to ensure that all messages sent by the server in the system are signed, thereby enabling verification of the message source through the signature; The aggregated signature module is used to aggregate the signatures of a sufficient number of nodes within the same shard that support the message when the Leader node of each shard needs a majority of nodes within the shard to reach a consensus on the same message and send the consensus result to other shards. The vote counting and block generation and distribution module is used to count the transaction verification information returned by each shard and generate k blocks based on the statistical results. The encoding module is used to generate encoded blocks. In each round of consensus, after LL verifies several transactions based on historical blocks, it divides the legitimate transactions into k parts, packages them into k blocks, and sends them to k original fragments. Each encoded fragment generates its own random number based on the VRF algorithm, and encodes the blocks stored in this round of consensus based on the random number and the original fragments that participated in its generation, to obtain the encoded blocks to be stored in this round of consensus for this encoded fragment. The storage module is used to store the blockchain data stored by the shard where this node is located.

2. A blockchain sharding method based on locally repaired system codes, characterized in that, A codeword in the partial repair system code contains n sign bits, which are divided into k original symbols and nk check symbols. Each check symbol is generated by a linear combination of several original symbols. The multiple servers acting as blockchain nodes are divided into n groups, each group representing a shard, resulting in a total of n shards, which are divided into k original shards and nk encoded shards. The block data stored in each encoded shard is generated by a linear combination of the block data stored in multiple original shards. All shards use the same Byzantine Fault Tolerant (BFT) algorithm for intra-shard consensus. Furthermore, one of the n shards is selected as the Leader shard. The Leader node of the Leader shard is denoted as LL. LL is responsible for consensus within its own shard and also participates in the consensus process of the entire blockchain sharding system. The original shard and m coded shards generated by it form several local verification groups. This ensures that when a shard in the system is bribed, the remaining m shards in its verification group can reach a consensus verification result. According to the principle of majority rule, the verification group can still correctly verify the legality of the transaction. Moreover, when a single shard is bribed, the content stored in the bribed shard can be recovered through decoding calculations by the local recovery group to which the shard belongs. The specific steps include the following: (1) At the beginning of each consensus round, each coding segment generates a random number of verifiable random number function (VRF), signs it, and broadcasts it to all other segments. Any segment can associate the coding segment with the original segment based on the random number sequence of all coding segments in this round. (2) LL collects the transaction information to be verified and stores the transaction information to be verified in the message buffer of the corresponding segment on LL according to the historical VRF random number sequence. When the total number of transaction information to be verified in the buffer reaches the threshold, the transaction information to be verified in the corresponding buffer is sent to each segment respectively. (3) The Leader node of each shard leads the nodes within the shard to verify the transaction to be verified, and reaches a consensus on the verification result through the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm. Then, the Leader node of each shard aggregates the signatures of the results from the nodes within the shard and returns the consensus result and aggregated signature to LL. (4) LL counts the consensus results of each shard. When the number of shards that are considered to be legitimate exceeds the threshold for a transaction to be verified, the system determines that the transaction is legitimate. When no shard in the system is bribed, any legitimate transaction is certified as legitimate. When a single shard in the system is bribed, a legitimate transaction can still be verified as legitimate by multiple other shards in the verification group, and the system is still secure and available. (5) When the system has accumulated a sufficient number of valid transactions, LL divides these valid transactions into k parts, that is, packages them into k blocks, and sends the k blocks to the original fragments corresponding to the numbers. Each original fragment distributes the received blocks to the coded fragments it participated in generating according to the VRF random number sequence generated in this round. (6) Each coded fragment generates its own coded block in the consensus of this round based on the block received in this round; (7) The original shards store their corresponding blocks and the transaction information therein; The encoded shard stores the unspent transaction output UTXO information from the block received from the original shard, saves the encoded block, and then deletes the received block.

3. The blockchain sharding method based on locally repaired system codes according to claim 2, characterized in that, The transaction received in step (2) consists of four parts: transaction header, historical transactions as support and their block height, newly generated transactions as output, and the signature of the transaction user; by combining the historical transactions and their block height information with the historical VRF random number sequence, LL can determine an original fragment and multiple encoded fragments that can verify the transaction.

Images