Patent ID: 12200054

DETAILED DESCRIPTION OF THE EMBODIMENTS

The specific implementations of the present disclosure are described below with reference to the accompanying drawings, such that those skilled in the art can better understand the present disclosure. It is important to note that in the following description, when detailed description of known functions and designs may dilute the main content of the present disclosure, details are omitted herein.

In order to combine the advantages of scalability and low node storage overhead of the blockchain sharding technology, and resolve the problem that the current sharding system is insecure and unavailable when a single shard is corrupted, the embodiments of the present disclosure provide a blockchain sharding method, system, and server based on locally repairable system codes, to introduce the encoding technology into the consensus process of the blockchain sharding system. Through the encoding technology, a plurality of shards are associated, such that the system can still ensure the reliability of transaction verification when a single shard is corrupted. The system includes a plurality of servers, and functional modules of each server include a VRF random number generation module, a new transaction buffer and distribution module, a transaction information verification module, an intra-shard consensus module, a node identity module, a signature aggregation module, a counting and block generation and distribution module, a encoding module, and a storage module.

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

The new transaction buffer and distribution module is used by the LL, after receiving a latest transaction, to determine, based on a stored block of each shard and the historical VRF random number sequence, shards capable of verifying the transaction, so as to buffer the transaction in buffers corresponding to different shards on the LL. When transaction information in buffer is sufficient, the LL sends the transaction information to corresponding shards for verification.

The transaction information verification module is used to determine legitimacy of the transaction based on the transaction information stored in the node.

The intra-shard consensus module is used to reach a consensus on a verification result among nodes in the shard, and the leader node in the shard returns the verification result to the LL.

The node identity module is used for node identity determining and signing, to ensure that all messages sent by the server in the system are signed, and sources of the messages are verified through signatures.

The signature aggregation module is used to aggregate signatures, when the leader node in each shard requires most nodes in the shard to reach a consensus on a same message and send a consensus result to other shards, signatures of a sufficient quantity of nodes in the shard that support the message.

The counting and block generation and distribution module is used to make statistics on transaction verification information returned by each shard and generate k blocks based on a statistical result.

The encoding module is used to generate an encoding block. In each round of consensus, after verifying a plurality of transactions based on historical blocks, the LL divides legitimate transactions into k parts, packages the k parts into k blocks, and sends the k blocks to k original shards. Each encoding shard generates a random number based on the VRF algorithm, and encodes, based on the random number, a block stored in this round of consensus by an original shard participating in generation of the encoding shard, to obtain an encoding block to be stored by the encoding block in this round of consensus.

The storage module is used to store blockchain data to be stored by the shard to which the node belongs.

For better understanding of the foregoing technical solution, the following describes the foregoing technical solution in detail with reference to the accompanying drawings and specific implementations.

Embodiment 1

This embodiment provides a blockchain sharding method, system, and server based on locally repairable system codes. As shown inFIG.1, each server represents a node in the blockchain sharding system. Functional modules of the server node include a VRF random number generation module, a new transaction buffer and distribution module, a transaction information verification module, an intra-shard consensus module, a node identity module, a signature aggregation module, a counting and block generation and distribution module, a encoding module, and a storage module.

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

The shards need a pair of public and private keys and a seed to generate the VRF random number. In this system, the public and private keys used by a shard to generate the VRF random number is the public and private keys of the leader node in the shard, and the seed used each time is the hash of the blocks stored by the shard. In this way, the system ensures the verifiability, fairness, randomness and tamper resistance of the random number, preventing a malicious node from controlling generation of the random number.

The new transaction buffer and distribution module is used by the LL, after receiving a latest transaction, to determine, based on a stored block of each shard and the historical VRF random number sequence, shards capable of verifying the transaction, so as to buffer the transaction in buffers corresponding to different shards on the LL. When transaction information in buffer is sufficient, the LL sends the transaction information to corresponding shards for verification.

The system stores the VRF random number sequences generated by all encoding shards in each round. Based on the VRF random number sequences generated in this round, after any node knows the height of the block in which the transaction is stored, it can divide the height of the block by the number of shards to obtain the round number in which the block is generated and the number of an original shard storing the block, and the LL buffers the transaction information into the LL buffers corresponding to different shards.

The transaction information verification module is used to determine legitimacy of the transaction based on the transaction information stored in the node.

When the system adopts the UTXO transaction model, the transaction information verification module of each server inquires, through the storage module, whether the UTXO consumed by this transaction is available and whether the face value of the UTXO 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, whether the shard knows account information of an expenditure account is inquired, and then whether the account balance is sufficient to pay the transaction is verified.

The intra-shard consensus module is used to reach a consensus on a verification result among nodes in the shard, and the leader node in the shard returns the verification result to the LL.

The nodes in the shard can communicate with each other, and the intra-shard consensus module can support various intra-shard consensus schemes, including but not limited to Proof of Work (POW), Proof of Stake (POS), PBFT, and so on. The default intra-shard consensus scheme is the PBFT consensus scheme.

The node identity module is used for node identity determining and signing, to ensure that all messages sent by the server in the system are signed, and sources of the messages are verified through signatures.

The signature aggregation module is used to aggregate signatures, when the leader node in each shard requires nodes in the shard to reach a consensus on a same message and send a consensus result to other shards, signatures of a sufficient quantity of nodes in the shard that support the message. The whole aggregation process is irreversible, information before aggregation cannot be obtained through the aggregated public key and signature, and the aggregated signature only needs to be verified once. The aggregated signature greatly reduces the cost of communication and verification while maintaining the information reliability.

The counting and block generation and distribution module is used to make statistics on transaction verification information returned by each shard. When more than half of the shards participating in the verification consider a transaction as legitimate, the transaction is verified as legitimate. When LL verifies a specific quantity of transactions as legitimate, it divides the transactions into k pieces, packages them into k blocks, and distributes them to k original shards.

The encoding module is used to generate an encoding block. In each round of consensus, after verifying a plurality of transactions based on historical blocks, the LL divides legitimate transactions into k parts, packages the k parts into k blocks, and sends the k blocks to k original shards. Each encoding shard generates a random number based on the VRF algorithm, and encodes, based on the random number, a block stored in this round of consensus by an original shard participating in generation of the encoding shard, to obtain an encoding block to be stored by the encoding block in this round of consensus.

The storage module is used to store blockchain data to be stored by the shard to which the node belongs. The storage module is built based on an existing database, and is divided into a blockchain storage module, a transaction information storage module, and a blockchain information storage module, respectively storing blocks or encoding blocks corresponding to the shard, latest UTXO state information or account balance information related to the block, and historical information of the VRF algorithm or historical information of other shards. The blocks stored in the transaction information storage module are related to a transaction model adopted by the system. When the system adopts the UTXO transaction model, the block stored by the transaction information storage module of the encoding shard is UTXO status information of all original blocks associated with the encoding block stored in the node. When the system adopts the account-balance model, the block stored in the transaction information storage module of a node is a latest state of an account involved in the blocks stored in the node. When the information of an account stored by the shard to which the node belongs is no longer the latest state, the account information is deleted, and a shard to which a node storing the latest state information of the account belongs is responsible for storing the latest balance state of the account.

Embodiment 2

The present disclosure provides a distributed consensus method based on system codes. The method includes a VRF random number generation and distribution phase, a transaction allocation phase, an intra-shard consensus phase, an inter-shard voting phase, a block generation phase, a block encoding phase, and a transaction information storage phase. As shown inFIG.2, the method includes the following steps:(1) At the beginning of each round of consensus, each encoding shard generates a VRF random number, signatures and broadcasts the VRF random number to all other shards. Any shard is capable of associating the encoding shard with original shards based on random number sequences of all the encoding shards in this round.(2) The LL collects to-be-verified transaction information, and stores, based on a historical VRF random number sequence, the to-be-verified transaction information in message buffers corresponding to different shards on the LL. When a total amount of to-be-verified transaction information in the buffers reaches the threshold, the to-be-verified transaction information in the corresponding buffer is sent to each shard.

The transaction includes four parts: a transaction head, a historical transaction used as a support and a height of a block in which the transaction is stored, and other information such as a signature of a transaction user of a newly generated transaction that is used as an output. Based on the historical transaction and information about the height of the block in which the historical transaction is stored, combined with the historical VRF random number sequence, the LL determines an original shard and a plurality of corresponding encoding shards that are capable of verifying the transaction. When the system adopts the UTXO model, the historical transaction refers to a generated transaction of the UTXO as the input. When the system adopts the account-balance model, the historical transaction refers to the last transaction of the user.(3) A leader node in each shard leads nodes in the shard to verify the to-be-verified transaction, to reach a consensus on a verification result by using a PBFT consensus algorithm; and the leader node in each shard aggregates signatures of the nodes in the shard on the result, and returns the consensus result and the aggregated signatures to the LL.(4) The LL makes statistics on the consensus results of the shards, and when a quantity of shards verifying the to-be-verified transaction to be legitimate exceeds a threshold, the system determines the transaction as a legitimate transaction. When no shard in the system is corrupted, any legitimate transaction is verified as legitimate. When a single shard in the system is corrupted, other shards in the verification group are still capable of verifying a legitimate transaction as legitimate, and the system is still secure and available.(5) After the system accumulates suffice valid transactions, the LL divides the valid transactions into k parts, that is, packages the valid transactions into k blocks, and sends the k blocks to the original shards with corresponding numbers. Each original shard distributes, based on the VRF random number sequences generated in this round, the received blocks to the corresponding encoding shards with the original shard.(6) Each encoding shard generates, based on the blocks received in this round, an encoding block of the shard in this round of consensus.(7) The original shard stores the corresponding block and transaction information in the block; the encoding shard stores corresponding UTXO information in the blocks received from the original shard, and stores the encoding block, and then deletes the received blocks.

Embodiment 3

The present disclosure provides a blockchain system based on system codes. As shown inFIG.3, in the system, a plurality of servers used as blockchain nodes are divided into n groups, each group represents one shard, the system includes n shards, the n shards include original shards and n−k encoding shards, block data stored in each encoding shard is generated through linear combination of block data stored in a plurality of original shards, and all the shards achieve intra-shard consensus through a same BFT algorithm. Further, one of the n shards is selected as the leader shard, the leader node in the leader shard is denoted as LL, and the LL is not only responsible for consensus within the leader shard, but also participates in the consensus process of the whole blockchain sharding system. All nodes in the same shard store the same block information, and nodes in different shards store different block information. No node stores all the blocks, but all nodes need to store a coding matrix generated with the VRF random numbers.

The specific embodiment of the present disclosure are described above to make those skilled in the art understand the present disclosure, but it should be clear that the present disclosure is not limited to the scope of the specific embodiment. For those of ordinary skill in the art, as long as various changes fall within the spirit and scope of the present disclosure defined and determined by the appended claims, these changes are apparent, and all inventions and creations using the concept of the present disclosure shall fall in the protection scope of the present disclosure.