A blockchain sharding method, a blockchain system and a cross-shard transaction processing method

Abstract

The application discloses a blockchain sharding method, a blockchain system and a cross-sharding transaction processing method. The blockchain sharding method uses the block header of the block of the last epoch consensus as a seed to calculate a random number for sharding reconstruction, and calculates the leader node of the current slot according to the block passed by the last consensus, thereby ensuring the unbiasedness of the random number generation and the unpredictability of the leader node, and ensuring the high efficiency and safety of the system. The cross-sharding transaction processing method adopts a parallel two-stage consensus mechanism, and the blocks can be more quickly voted for consensus within the shard. Further embodiments also disclose batch processing of transactions and generation of a Merkle sub-tree, which is used for unified verification of transactions sent to the same target shard, effectively reduces the system overhead, and improves the cross-sharding transaction processing efficiency.

Description

A blockchain sharding method, a blockchain system, and a cross-shard transaction processing method 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-shard transaction processing method. Background Technology

[0002] Sharding technology is used to solve the scalability problem of blockchain systems. The parallel processing of different transactions by multiple shards can improve the throughput of traditional blockchains and effectively reduce transaction confirmation latency. Each blockchain shard not only processes transactions within its own shard, but also transmits a large number of cross-shard transactions to other shards. Balancing system performance and security is the current focus of blockchain sharding systems. However, many existing sharding protocols often cannot achieve both, either having defects in system security or sacrificing system performance for security.

[0003] For transaction consensus within a shard, a leader node needs to be elected to produce blocks, and other nodes within the shard must reach a consensus on the blocks. Most existing sharding protocols require each shard's leader node to continuously produce blocks within a certain period, and the fact that the leader node is known in advance makes it easy for malicious nodes to launch targeted attacks, weakening system security. Furthermore, when the leader node is malicious or under attack, a complex leader node replacement process is required, which degrades system performance. In addition, most sharding protocols use Byzantine fault-tolerant consensus mechanisms, further reducing consensus efficiency.

[0004] For cross-shard transactions, malicious nodes may send incorrect transaction information to other shards. Since each shard maintains different information independently, the receiving shard cannot verify the validity of the cross-shard transaction. To ensure transaction security, some existing sharding protocols attach a large amount of proof information when sending transactions, which introduces excessive communication overhead to the system.

[0005] In addition, existing random number generation methods either have biases or are computationally and communication-intensive. Distributed systems like blockchain need better methods to quickly generate unbiased random numbers.

[0006] In summary, more efficient and secure consensus mechanisms and transaction processing methods are needed to address the shortcomings in the performance and security of existing blockchain systems. Summary of the Invention

[0007] Based on this, the present invention proposes a blockchain sharding method, a blockchain system, and a cross-shard transaction processing method, designs a new intra-shard consensus mechanism and transaction processing mechanism, and ensures the scalability of the blockchain system, enhancing the system performance and security of intra-shard transactions and cross-shard transactions.

[0008] Firstly, a blockchain sharding method includes:

[0009] The reference committee obtains the block headers of all consensus-passed blocks in the current epoch, generates a random number for the next epoch based on the block headers, and completes the sharding reconstruction based on the random number for the next epoch.

[0010] Within a shard, nodes calculate the leader node for the current slot based on the previous block passed by consensus.

[0011] Furthermore, generating random numbers for the next epoch based on the block header includes:

[0012] XOR all block headers to obtain the seed for the next epoch, and calculate the random number for the next epoch based on the seed.

[0013] Furthermore, the fragment reconstruction based on the random number of the next epoch includes:

[0014] The new node takes the random number of the next epoch as a new PoW problem and provides a solution. The reference committee verifies the correctness of the solution and randomly assigns the new node to the shard according to the finite cuckoo principle, thus completing the shard reconstruction for the next epoch.

[0015] Furthermore, the above method also includes:

[0016] Based on the sharding reconstruction results, the node change information is broadcast to each shard, and each shard generates a sharding node table based on the node change information.

[0017] Furthermore, the leader node for the current slot is calculated based on the previous block passed by consensus, including:

[0018] Obtain the block header of the previous block that passed consensus;

[0019] Each node uses the block header and the current slot number as a seed to input a random number generator to calculate a random number;

[0020] The random number generator maps random numbers to a node, and the mapped node is the leader node of the current slot.

[0021] Furthermore, to ensure the unbiasedness and security of leader node rotation, the node uses the node signature information in the block header and the current slot number as a seed input to the random number generator to calculate a random number.

[0022] Furthermore, the random number generator uses a pseudo-random number generator.

[0023] Furthermore, a random oracle is used as a pseudo-random number generator.

[0024] Secondly, the present invention provides a blockchain system, including a reference committee and system shards;

[0025] The reference committee is used to refactor the system shards according to the blockchain sharding method of the first aspect, wherein the leader node of each system shard is calculated according to the blockchain sharding method of the first aspect.

[0026] Thirdly, this invention provides a cross-shard transaction processing method, applied to the blockchain system of the second aspect, executed at the source shard, the method comprising:

[0027] Transaction packaging process: The leader node packages the transaction into a block and broadcasts it within the fragment;

[0028] Block consensus process: Each node votes on the received block and broadcasts the voting results;

[0029] Transaction sending process: The leader node sends the consensus-passed block to the target shard;

[0030] The transaction packaging process of the current block and the consensus process of the previous block are executed in parallel.

[0031] Furthermore, the transaction packaging process includes:

[0032] The leader node packages the transactions into a block and broadcasts the block and block digest within the shard. The block digest is used to enable nodes within the shard to pre-verify the block.

[0033] Furthermore, the block consensus process includes:

[0034] Nodes within a shard receive the block digest after the first time interval and the block after the second time interval;

[0035] Nodes vote on the consensus of blocks and broadcast the voting results within the shards. When more than a set number of nodes agree on a block, the nodes write the block into their local ledger.

[0036] Furthermore, the parallel execution process of the above method specifically includes:

[0037] While the leader node packages the transactions into the current block, the nodes in the shard vote on the consensus of the previous block. Also, while the leader node broadcasts the current block within the shard, the nodes in the shard write the previous block into their local ledger.

[0038] Furthermore, during parallel execution, the leader node waits for the consensus vote of the previous block to finish before encapsulating the current block.

[0039] Furthermore, to prevent the current block from being repackaged due to the invalidity of the previous block consensus, which would damage system performance, when the leader node receives the broadcast of the previous block, it verifies the previous block and packages transactions that are mutually exclusive with the transactions in the previous block.

[0040] Furthermore, the transaction packaging process also includes:

[0041] When the leader node packages a transaction into the current block, it constructs the Merkle root of the transaction and writes it into the block header of the current block.

[0042] Furthermore, to reduce communication and computational overhead, the leader node constructs the Merkle root of the transaction through the following process:

[0043] Transactions are clustered based on the target shard address. Transactions sent to the same target shard are sorted by their hash values. Merkle subtrees are constructed for transactions sent to the same target shard. Different Merkle subtrees are merged into a complete Merkle tree. The Merkle root of the Merkle tree is written into the block header of the current block.

[0044] Furthermore, the transaction sending process includes:

[0045] The leader node sends transactions destined for the same target shard in batches to the corresponding target shard, while simultaneously broadcasting the block header and the roots of all Merkle subtrees.

[0046] Furthermore, the block digest includes at least:

[0047] The current block sequence number, current slot sequence number, block hash value, and leader node identity identifier.

[0048] Fourthly, the present invention provides a cross-shard transaction processing method, applied to the blockchain system of the second aspect, executed in the target shard, the method comprising:

[0049] Receive blocks sent by the source fragment, and verify and execute transactions within the block that belong to this fragment for processing.

[0050] Furthermore, the verification of transactions within the block that belong to this shard includes:

[0051] Receive transactions sent in batches from the source fragments, reconstruct the root of the corresponding Merkle subtree based on the hash value of the transaction, and reconstruct the Merkle root based on the roots of other Merkle subtrees;

[0052] The reconstructed Merkle root is compared with the Merkle root in the block header. If they are the same, the transaction is valid and executable; otherwise, the transaction is invalid.

[0053] Furthermore, to prevent the leader node from forging other nodes within the shard and their signatures, the above method also includes:

[0054] The nodes within the target shard verify whether there is an invalid node signature in the block header based on the shard node table.

[0055] Fifthly, the present invention provides a blockchain sharding system, including source shards and target shards;

[0056] The source shard is used to implement the cross-shard transaction processing method in the third aspect, and the target shard is used to implement the cross-shard transaction processing method in the fourth aspect.

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

[0058] The memory is used to store programs;

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

[0060] 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-shard transaction processing method.

[0061] Compared with existing sharding systems and cross-shard transaction processing methods, the present invention has the following advantages:

[0062] The sharding method provided by this invention uses the block headers of all consensus-passed blocks within an epoch as seeds to calculate the random number for the next epoch during shard reconstruction. Then, it calculates the leader node for the current slot based on the consensus-passed block from the previous epoch. The generation of the random number for each epoch is based on blocks generated backwards on the chain, and the generation of the leader node also depends on the latest consensus-passed block, ensuring the unbiasedness and unpredictability of random number generation. Even with malicious nodes, the system remains highly efficient and secure, while also improving the efficiency of leader node election. The cross-shard transaction method provided by this invention improves the traditional serial three-phase consensus mechanism into a parallel two-phase consensus mechanism for consensus within a shard. Within a shard, consensus voting on blocks proposed by the leader node can be completed faster, enabling the system to achieve high throughput and low latency. Furthermore, in cross-shard transactions, transactions sent to the same shard are processed in batches and a unified Merkle proof is attached to simultaneously verify this batch of transactions, ensuring system security and effectively reducing system computational overhead. Attached Figure Description

[0063] 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.

[0064] Figure 1 shows the blockchain system framework provided in an embodiment of the present invention;

[0065] Figure 2 illustrates the implementation flow of a blockchain sharding method provided in an embodiment of the present invention;

[0066] Figure 3 illustrates the implementation flow of a cross-shard transaction processing method provided in an embodiment of the present invention;

[0067] Figure 4 is a schematic diagram of a parallel two-stage consensus mechanism provided by an embodiment of the present invention;

[0068] Figure 5 is a schematic diagram of another parallel two-phase consensus mechanism provided by an embodiment of the present invention;

[0069] Figure 6 is a schematic diagram of the block structure provided in an embodiment of the present invention;

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

[0071] 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.

[0072] In blockchain sharding systems, nodes within each shard not only handle transactions within their own shard but also a large number of cross-shard transactions. Currently, BFT-type consensus mechanisms are commonly used. To ensure security, these mechanisms often require multiple rounds of communication (at least three rounds) to reach consensus. These mechanisms assume a good network synchronization environment within the shard and design relatively complex communication processes. Some mechanisms require view modifications to replace the leader node in the presence of malicious nodes, reducing the efficiency of intra-shard consensus. Furthermore, current sharding systems, where the leader node continuously produces blocks over a period of time and is known in advance, make the leader node more vulnerable to malicious attacks. As for cross-shard transactions, existing solutions are still insufficient in ensuring transaction security or cannot balance performance and security.

[0073] Obtaining randomness is a crucial and challenging issue in blockchain, especially in sharded systems. Shard construction and leader election both rely on randomness. However, existing random number generation methods cannot fully guarantee unbiasedness. For example, the randomness seed used in Algorand's VRF function and the PoW consensus result used in Elastico can be biased by malicious nodes. While some methods guarantee unbiased generation, such as the PVSS scheme used by Ouroboros, Omniledger's use of VRF for unbiased leader election, and RapidChain's use of VSS for key classification, all require complex communication processes, resulting in significant communication overhead and thus low efficiency.

[0074] To address the above issues, this invention proposes a blockchain sharding method, a blockchain system, and a cross-shard transaction processing method, which involve unbiased leader node rotation, an efficient intra-shard consensus mechanism, and a cross-shard transaction processing mechanism, which will be described in detail in the following embodiments.

[0075] Figure 1 illustrates the basic model of the blockchain system of this invention, which includes the following four parts: leader node rotation, intra-shard consensus, cross-shard transaction processing, and shard reconstruction. An epoch contains multiple slots. At the beginning of each slot, a new leader node is elected for each shard. At the end of each epoch, shard reconstruction occurs, during which the nodes within the shard change. These four parts will be explained in detail below.

[0076] Based on the system model shown in Figure 1, Figure 2 illustrates an implementation process of the blockchain sharding method provided in this embodiment of the invention. It can be correlated with the sharding reconstruction and leader node rotation in the model shown in Figure 1. The process is explained starting with sharding reconstruction.

[0077] (1) Fragmentation and reconstruction process

[0078] The reference committee obtains the block headers of all consensus-passed blocks in the current epoch, generates a random number for the next epoch based on the block headers, and completes the sharding reconstruction according to the random number for the next epoch.

[0079] Specifically, the premise of performing the above-mentioned shard reconstruction in this embodiment is that for each block that has passed consensus, its block header is broadcast to other shards of the system (including the reference committee) at the same time as sending the transaction. Therefore, the reference committee can obtain the block headers of all blocks that have passed consensus within an epoch, and generate a random number for the next epoch for shard reconstruction based on this.

[0080] Generally, a block header includes at least the following information: block hash value, timestamp, block sequence number, slot number, epoch number, shard identifier, and leader node signature information. Among these, the slot number and epoch number are public and cannot be manipulated or tampered with, while the signature information is verified by nodes within the shard. Therefore, the random number generated based on the block header is unbiased.

[0081] Furthermore, the process of generating random numbers for the next epoch is as follows:

[0082] XOR all block headers to obtain the seed for the next epoch, and calculate the random number for the next epoch based on the seed.

[0083] Furthermore, the process of reconstructing the fragments based on random numbers is as follows:

[0084] When a new node joins the system, it provides a solution to the new PoW problem by using the random number of the next epoch as the solution. The reference committee verifies the correctness of the solution and randomly assigns the new node to a shard according to the finite cuckoo principle, thus completing the shard reconstruction for the next epoch.

[0085] Specifically, the finite cuckoo principle is an improvement on the traditional cuckoo principle. The traditional cuckoo principle requires re-electing all shards and reshuffling all nodes, which incurs significant computational overhead, making shard reconstruction time-consuming and failing to significantly improve sharding system performance. The finite cuckoo principle, a sharding solution proposed by RapidChain, avoids re-electing all shards. Instead, it divides shards into active and inactive shards based on transaction activity. When a new node joins, a reference committee randomly assigns it to an active shard and randomly distributes a fixed number of nodes from that active shard into different inactive shards.

[0086] Furthermore, during sharding reconstruction, node change information of the shards is broadcast to each shard in the system. Each shard generates a state block based on the node change information. The state block contains a sharding node table representing all shards. Each node in the system stores and maintains this sharding node table, which includes the valid public keys of all nodes and can be used to verify the legality of node signatures.

[0087] (2) Leadership rotation process

[0088] Within a shard, nodes calculate the leader node for the current slot based on the previous block passed by consensus.

[0089] Specifically, leader node rotation occurs within each shard starting from the beginning of each slot. This invention uses the previous block that has passed consensus as the seed for random number calculation. The leader node rotation of each slot is based on the previous block that has passed consensus. Since the block has passed shard consensus and the block's signature information has been verified by all nodes within the shard, this invention proposes a chain-based leader node rotation process to ensure the randomness of the system.

[0090] Furthermore, the signature information in the block header and the sequence number of the current slot can be extracted as a seed. The seed is then input into a random number generator to calculate a random number. The random number is mapped to a node, and the node determines the leader node based on the mapping result.

[0091] Specifically, pseudo-random number generation functions, such as random oracles, can be used as random number generators.

[0092] Referring to Figures 1 and 2 and their embodiments, it can be seen that in the (e-1)th epoch shown in Figure 1, the leader node of the shards in different slots changes. For example, the leader node of shard 1 changes from node i to node c, the leader node of shard 2 changes from node a to node k, and the leader node of shard 3 changes from node l to node f. In the eth epoch, the node members of shards 1 to 3 change. Node h is assigned from shard 3 to shard 1, node d is assigned from shard 1 to shard 3, shard 2 adds node m and removes node a, and the leader node within the shards also changes in the two consecutive slots in the eth epoch.

[0093] Referring to Figure 3, which illustrates an implementation flow of the cross-shard transaction processing method provided by an embodiment of the present invention, it can be correlated with intra-shard consensus and cross-shard transaction processing in the model shown in Figure 1. The process will be described starting with intra-shard consensus.

[0094] (1) Consensus process within a segment

[0095] The intra-shard consensus mechanism provided in this embodiment of the invention is a two-stage parallel consensus mechanism, consisting of a first-stage transaction packaging process and a second-stage block consensus process. The two-stage consensus mechanism will be explained below.

[0096] ① Transaction packaging process

[0097] The leader node of a shard packages transactions into blocks and broadcasts them within the shard.

[0098] Specifically, the leader node packages transactions into a block and broadcasts the block and its block digest within the shard. The block digest is used to allow nodes within the shard to pre-verify the block. Because the block digest is small, other nodes in the shard will receive the block digest first and then the complete block. Typically, the block digest includes at least the current block's sequence number, the current slot number, the block hash value, and the leader node's identity.

[0099] Since blockchain is a distributed system, the intra-shard consensus mechanism proposed in this embodiment of the invention does not require the clocks of nodes within the shard to be synchronized. Each node can asynchronously receive blocks and block digests to complete its own voting on the blocks.

[0100] Furthermore, since the blocks package cross-shard transactions, and the states between shards are independent, the target shard receiving the cross-shard transactions cannot directly verify whether the transaction has been confirmed through consensus in the source shard. Generally, the Merkle root of the transaction can be constructed and written into the block header when packaging the block for the target shard to verify the correctness of the transaction. The common practice is to attach a Merkle root to each cross-shard transaction, that is, to attach a complete Merkle path to each transaction.

[0101] Furthermore, the aforementioned Merkle root appending method leads to significant system overhead. To address this issue, this embodiment of the invention employs a Merkle root pruning method. In a specific example, when the leader node packages transactions, it first clusters the transactions according to the target shard address. Transactions sent to the same target shard are sorted by their hash values. Merkle subtrees are constructed for transactions sent to the same target shard, and different Merkle subtrees are merged into a complete Merkle tree. The Merkle root of the Merkle tree is written into the block header of the current block. Each Merkle subtree has its own Merkle root. Therefore, a batch of transactions sent to the same target shard only needs to have one Merkle root appended, i.e., the root of the Merkle subtree corresponding to this batch of transactions. The target shard can use a single Merkle root to verify a batch of transactions, significantly reducing system overhead.

[0102] ② Block consensus process

[0103] Each node within a shard votes on the received block and broadcasts the voting results.

[0104] Specifically, generally, nodes within a shard receive the block digest after the first time interval and the block after the second time interval. After receiving the block, nodes vote on the consensus of the block and broadcast the voting results within the shard. When more than a set number of nodes agree on the block, the nodes write the block to their local ledger. In a further scenario, it can be set that if more than half of the nodes agree on the block, it is considered valid and written to the local ledger; otherwise, the block is considered invalid and proceeds to the next slot.

[0105] Common consensus mechanisms generally involve three rounds of communication, including pre-preparation, preparation, and block submission. The two-stage consensus mechanism provided in this embodiment of the invention can be regarded as the pre-preparation stage in the conventional mechanism in the first stage of transaction packaging and block broadcasting, and the block consensus voting in the second stage can be regarded as a compression of the preparation and block submission stages in the conventional mechanism.

[0106] The following uses Figure 4 to illustrate how the two-phase consensus mechanism of this invention is executed in parallel.

[0107] Each slot can be divided into the two stages described above: transaction packaging and block consensus. In the process, while the leader node is packaging transactions for the newly proposed block, the nodes within the shard are packaging transactions for the slot. The proposed block consensus vote. It's easy to understand that if the slot... If no block has been proposed, then the node is currently voting in consensus on the slot. The proposed block, and similarly for other types of scenarios, involves the leader node broadcasting the packaged block within the shard, while nodes within the shard write the consensus-passed block into their local ledger.

[0108] Furthermore, the blockchain generates a chained ledger, and the parallel execution process can easily lead to the leader node being unable to determine which block the current block should be linked to before the consensus vote of the previous block ends. Therefore, the leader node should wait for the consensus vote of the previous block to end before encapsulating the current block.

[0109] Furthermore, if the consensus result of the previous block is invalid, the transactions in the current block may need to be repackaged, which will impair system performance. Therefore, when the leader node that packages the current block receives the broadcast of the previous block, it first verifies the previous block and packages the transactions that are mutually exclusive with the previous block (e.g., transactions sent by different accounts). In this way, the current block can be generated regardless of whether the previous block is valid or not.

[0110] (2) Cross-shard transaction processing

[0111] The leader node of the source shard sends the consensus-passed block to the target shard.

[0112] Specifically, during the transaction packaging process described above, Merkle subtrees corresponding to transactions of the same target shard have been generated. The leader node will send transactions destined for the same target shard in batches to the corresponding target shards, while broadcasting the block header and the roots of all Merkle subtrees.

[0113] After receiving a transaction, the target shard needs to verify it. Specifically, the target shard reconstructs the root of the corresponding Merkle subtree based on the transaction's hash value, and reconstructs the Merkle root based on the roots of other Merkle subtrees. It then compares the reconstructed Merkle root with the Merkle root in the block header. If they match, the transaction is valid and executable; otherwise, the transaction is invalid. During the shard reconstruction process, it was mentioned that each node maintains a shard node table, which includes the valid public keys of all nodes. Therefore, after receiving the block header, the target shard can verify the presence of any illegitimate node signatures by comparing the signature information in the shard node table and the block header.

[0114] Based on the system model shown in Figure 1 and the description of each process in the above embodiments, the following embodiments further illustrate the blockchain sharding method and cross-shard transaction processing method of the present invention through specific scenarios and related calculations.

[0115] Each epoch has multiple slots. Assuming there are n nodes in the system, during system initialization, these nodes are randomly assigned to m partitions. Each partition has... Each node in a shard will elect a new leader node at the beginning of each slot.

[0116] To prevent Sybil attacks, each node needs to be authenticated and generate an identity certificate when joining the system.

[0117] Similar to many fragmentation protocols, the system in this embodiment can use the Gossip protocol for network information transmission, meaning that over a period of time... Within this framework, any information sent or forwarded by a particular honest node will be transmitted to all honest nodes. To address the poor responsiveness issue inherent in any synchronous consensus mechanism and to achieve long-term responsiveness, each shard periodically (e.g., weekly or daily) updates its consensus mechanism for new data. An agreement was reached, similar to existing sharding protocols.

[0118] In addition to consensus within shards, the blockchain sharding system provided in this embodiment is a partially synchronized system and is based on an account model. Each account has an independent state, and which shard stores and maintains the account state depends on the account address. The account address is mapped to the shard according to the output of a random oracle.

[0119] This embodiment constructs a threat model for the sharding system similar to existing blockchains. A Byzantine adversary can control less than 1 / 3 of the system's nodes. Communication channels within the shards are synchronous, thus achieving optimal network failure resilience of 1 / 2 within each shard. The Byzantine adversary can only destroy a fixed set of nodes at the beginning of each epoch, and this destroyed set remains unchanged within that epoch. It is also assumed that the adversary can launch targeted attacks against the leader node.

[0120] To achieve randomness, all nodes can access an external random oracle.

[0121] Similar to the aforementioned embodiments, this embodiment describes four parts: leader node rotation, intra-shard consensus, cross-shard transaction processing, and shard reconstruction.

[0122] The sharding process and cross-shard transaction processing of the system can be roughly described as follows: a new leader node is selected in each slot based on an unbiased random number to propose a block; intra-shard consensus is executed for the blocks proposed by the leader node; when consensus is reached, cross-shard transactions are sent and processed; the period between two epochs is the sharding reconstruction phase, during which shard nodes are reallocated.

[0123] Next, we will explain the parallel two-phase consensus mechanism proposed in this embodiment for consensus within a shard.

[0124] The two-phase consensus mechanism consists of two phases: Phase 1, transaction packaging and block broadcasting; and Phase 2, consensus voting and block insertion. Essentially, this is a synchronous consensus mechanism that achieves optimal network failure resilience of 1 / 2 in each shard, thus allowing for a total resilience of 1 / 3.

[0125] ① Transaction packaging and block broadcasting

[0126] In each slot, the leader node of that slot packages the transactions into a block and broadcasts the block and block digest within the shard. The block digest includes at least the current block's sequence number, the current slot number, the block hash value, and the leader node's identity information, used for pre-verification of the block. Generally, nodes receive the block digest before receiving the complete block.

[0127] Synchronous network models typically have a defined upper limit on latency; therefore, this embodiment defines the upper limit of the broadcast latency for block digests as follows: This indicates that after the leader node broadcasts the block and block digest, the nodes within the shard will be in the same shard for a specified time. Internally received block digest; and the total broadcast delay upper limit is defined as . This indicates that after the leader node broadcasts the block and block digest, the nodes within the shard will be in the same shard for a specified time. The internal input includes blocks and block digests.

[0128] The consensus mechanism in this embodiment does not require clock synchronization between nodes. Suppose that a node receives a block digest within the period after the leader node broadcasts it. At this time, the node will start its clock and wait for the block. During this period, it is not necessary for all nodes in the shard to synchronize their clock information. It is only necessary for the time stream of each node to be consistent.

[0129] ② Consensus voting and block insertion

[0130] Under normal circumstances, the node's waiting time is at most Afterwards, the complete block will be received, and voting will begin. The validity of transactions will be verified, and the voting results will be broadcast within the fragment. Here, the upper limit for the broadcast delay of the voting results is defined as follows: Because the clocks of the nodes are not synchronized, each node has to wait a certain amount of time during the consensus voting phase. This ensures that each node within a shard receives the voting results from other nodes. This embodiment sets more than... When all nodes agree on a block, one node submits the block to its local ledger; otherwise, the block is considered invalid and enters a new slot.

[0131] This embodiment utilizes the characteristics of intra-shard synchronization networks for the two-phase consensus voting deadline. This reduces communication overhead without compromising system security. Furthermore, due to the small number of nodes within each shard, the consensus process is short. This characteristic allows for... , , By keeping the scope very small, the intervals between slots are shortened and consensus efficiency is improved.

[0132] Based on the above description of the two-phase consensus mechanism, the following explains how this mechanism is executed in parallel. The consensus mechanism can be broken down into four sequential steps: transaction packaging, block broadcasting, consensus voting, and block insertion. To achieve parallel execution, these four steps are reorganized.

[0133] Specifically, as shown in Figure 5, in slot In the middle, the leader node is the newly proposed block. While packaging transactions, the nodes within the same block are based on the previous block. Consensus voting. A slot can produce 0 or 1 blocks. No block was proposed; the block was voted on by the nodes in consensus. When the leader node broadcasts a block At the same time, nodes within the chip insert blocks into their local ledger. .

[0134] The default node here is in the consensus block. Because the blockchain generates a chain of ledgers, parallel execution processes can easily lead to block overflows. The leader node cannot determine the block when consensus is not reached. The link should be placed on which block, therefore the leader node should wait for that block. Block sealing after consensus voting ends And construct the block header, such as the block. When deemed valid, the current block is... The link should be at after.

[0135] Secondly, if the block The consensus result is invalid, which may lead to block... Transactions need to be repackaged, which will degrade system performance. It's easy to understand that all nodes in a shard, including the leader node, can receive the broadcast block, and the leader node of the current slot is not necessarily the same as the leader node of the previous slot; therefore, repackaging blocks... The leader node can receive blocks First verify , with Mutually exclusive transactions (e.g., transactions sent from different accounts) are packaged first, so that regardless of the block... Blocks can be generated regardless of whether they are valid or not. .

[0136] The parallel two-phase consensus mechanism prioritizes parallel communication over computation. Therefore, in practical design, transaction packaging and block insertion can be made less time-consuming than consensus voting and block broadcasting, allowing nodes to reduce waiting time. or If a node receives voting results or block digests from other nodes before the end of its waiting period, it can verify the received information while waiting for the timeout to expire.

[0137] Based on the above-mentioned parallel two-phase consensus mechanism, the leadership node rotation will be further explained below.

[0138] At the start of each slot, the shard calculates a new random number to elect the leader node for that slot. Specifically, when a node starts a new slot, it extracts signature information (e.g., block signature) from the latest consensus-completed block. This is due to slot Start Block (Consensus not yet reached) Nodes use the extracted signature information and the current slot number as a seed input to a publicly accessible pseudo-random number generation function. This function maps the seed value to a node, which becomes the leader node of slot t, responsible for proposing blocks. .

[0139] Figure 6 shows the information included in the block header. In this embodiment, the leader node writes the current slot number and signature information into the block header when generating a block. This allows each node to use information from the latest consensus-completed block as a seed to calculate the leader node's identity. One possible calculation expression is given below:

[0140]

[0141] in, This represents a random oracle that maps inputs to a node, and the leader node represents the leader node. For blocks Signature information .

[0142] The following explains the process of cross-shard transaction processing.

[0143] Typically, because shards are state-independent, to prevent malicious nodes from sending fake transactions or generating fake signatures, cross-shard transaction transmission requires attaching a proof to the transaction for the target shard to verify whether the transaction has passed consensus in the source shard. A common practice is to attach the Merkle root of the complete Merkle tree to each transaction, which leads to significant system overhead. To address this issue, especially when sending a large number of cross-shard transactions, this embodiment improves the method of attaching the Merkle root.

[0144] Specifically, referring to Figure 6, when packaging transactions, the leader node first clusters the transactions by target shard address and sorts them by transaction hash value. For transactions sent to the same target shard, it constructs a Merkle subtree, merges different Merkle subtrees into a complete Merkle tree, and writes the Merkle root of the Merkle tree into the block header of the current block. Since a Merkle subtree has its own Merkle root, a batch of transactions sent to the same target shard only needs to have one Merkle root appended—the root of the Merkle subtree corresponding to this batch of transactions. The target shard can use the Merkle root of the subtree to verify a batch of transactions, significantly reducing system overhead.

[0145] Once a block is confirmed through consensus, the leader node that produced the block sends the cross-shard transactions contained in the block in batches to the corresponding target shards. When sending cross-shard transactions, the leader node broadcasts the block header to other shards. To ensure that cross-shard transactions can be verified by the target shards, the leader node also needs to broadcast the roots of all Merkle subtrees to the system.

[0146] After receiving a transaction, the target shard needs to verify it. Specifically, the target shard reconstructs the root of the corresponding Merkle subtree based on the transaction's hash value, and reconstructs the Merkle root based on the roots of other Merkle subtrees. It then compares the reconstructed Merkle root with the Merkle root in the block header. If they match, the transaction is valid and executable; otherwise, the transaction is invalid. Each node maintains a shard node table, which includes the valid public keys of all nodes. Therefore, after receiving the block header, the target shard can verify the presence of an invalid node signature by comparing the signature information in the shard node table and the block header.

[0147] The sharding reconstruction process in this embodiment is similar to RapidChain, except for the generation of random numbers for each epoch. Specifically, this embodiment proposes a chain-based random number generation method. As described above, the block header of each consensus-passed block is broadcast to the network. The reference committee can then obtain all block headers from the most recent epoch, perform an XOR operation on the block headers to obtain the seed for the next epoch, and use this seed to generate random numbers. During sharding reconstruction, the node change information of each shard is broadcast to the network. Each shard generates a state block based on the node change information. The state block contains a sharding node table representing all shards, and each node in the system stores and maintains this sharding node table.

[0148] The chain-based random number generation scheme proposed above for leader rotation and sharding refactoring ensures that the slot sequence number is public and immutable, and the random oracle mapping the seed to a node is accessible and cannot be manipulated or destroyed by a single node. Regarding the signature information used, since each node generates an identity verification to defend against Sybil attacks upon joining the system and is randomly assigned to a shard; and since nodes update the shard node table after each sharding refactoring, it is impossible for the leader node to forge multiple legitimate signatures within a single shard, as long as the number of malicious nodes within a single shard does not exceed a set limit (e.g., half the number of nodes in the shard), and the signature requires verification from all nodes within the shard, this approach balances security and unbiasedness.

[0149] To address the issue that the leader node is known in advance in existing sharding protocols, the leader rotation scheme in this embodiment uses the signature information of the latest consensus-completed block to calculate the leader node for each slot. Therefore, the new random number cannot be predicted before the block consensus is completed, and thus the ownership of the leader node cannot be known in advance.

[0150] Now let's explain the security of consensus within shards. Assume an honest node... exist When a block digest of a block is received, another honest node... exist If the same block digest is received at the same time, then... Let's assume a worst-case scenario. When node wait After receiving the block, the node begins voting. We've been waiting The node then began voting and broadcasting the voting results. We need to wait. Ensure node is received The voting results are used to determine the waiting time for all nodes. Consensus was reached internally.

[0151] When a malicious leader node attempts to send a block with a different value to other nodes, the other nodes can detect the attack based on the block digest. In this case, nodes do not need to wait for the waiting period to end before voting can begin; they can start voting immediately. If a malicious node tries to broadcast a different vote result, it will also be detected by honest nodes within the shard, and the malicious node's vote will be considered invalid. Furthermore, when a malicious leader node launches a silence attack (i.e., does not send messages), the nodes in the shard will not receive blocks within the waiting period, and will automatically enter a new slot and elect a new leader node. This process continues as long as the number of malicious nodes does not exceed [a certain threshold]. This will not affect the block consensus, because honest nodes will always receive a sufficient number of votes within the waiting time.

[0152] In this embodiment, regardless of whether the current leader node is good or bad, a new leader node is automatically elected at the start of a new slot. Each honest node has the same view of the validity of the blocks proposed in each slot. Therefore, regardless of whether the leader node is malicious, all honest nodes will automatically elect the next leader node after the voting phase ends. Thus, a valid block will ultimately be generated by an honest leader node.

[0153] In addition, each shard periodically (e.g., weekly or daily) agrees on the duration limit. If changes in the network environment cause consensus to pause, preventing nodes from receiving enough votes within the waiting time, the nodes will renegotiate the duration limit and resume the consensus process.

[0154] Regarding communication overhead, since this embodiment clusters transactions according to the target shard and generates Merkle subtrees for each, assuming a block has N cross-shard transactions, the transactions are sent to the shards... The number of transactions is For transactions targeting the same shard, only the root of a Merkle subtree needs to be appended for verification, thus the additional communication overhead for each transaction is... This achieves lower overhead.

[0155] The blockchain system provided in this application embodiment can be applied to electronic devices. Figure 7 shows a hardware structure block diagram of this electronic device. Referring to Figure 7, the hardware structure of the 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;

[0156] 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;

[0157] 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.

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

[0159] The memory stores a program, which the processor can call. The program is used to: implement the various processing flows in the aforementioned blockchain sharding scheme, or to implement the various processing flows of the aforementioned source shard and / or target shard in the cross-shard transaction processing scheme.

[0160] 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 each processing flow in the aforementioned blockchain sharding scheme, or to implement each processing flow of the aforementioned source shard and / or target shard in the cross-shard transaction processing scheme.

[0161] 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.

[0162] 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, include: The reference committee obtains the block headers of all consensus-passed blocks in the current epoch, generates a random number for the next epoch based on the block headers, and completes the sharding reconstruction based on the random number for the next epoch. Nodes within a shard calculate the leader node for the current time slot based on the previous block that passed consensus. Specifically, this involves: obtaining the block header of the previous block that passed consensus; each node within the shard using the block header and the current time slot number as a seed to input a random number generator to calculate a random number; and the random number generator mapping the random number to a node, which becomes the leader node for the current time slot.

2. The blockchain sharding method according to claim 1, characterized in that, The method of generating random numbers for the next epoch based on block headers includes: performing an XOR operation on all block headers to obtain a seed for the next epoch, and calculating random numbers for the next epoch based on the seed.

3. The blockchain sharding method according to claim 1, characterized in that, The process of reconstructing the shards based on the random number of the next epoch includes: the new node takes the random number of the next epoch as a new PoW problem and provides a solution; the reference committee verifies the correctness of the solution and randomly assigns the new node to the shards according to the finite cuckoo principle, thus completing the shard reconstruction for the next epoch.

4. The blockchain sharding method according to claim 1, characterized in that, The method further includes: broadcasting node change information to each shard based on the sharding reconstruction result, and generating a sharding node table for each shard based on the node change information.

5. The blockchain sharding method according to claim 1, characterized in that, Each node within the segment uses the signature information in the block header and the sequence number of the current time slot as a seed to input a random number generator to calculate a random number.

6. The blockchain sharding method according to claim 1, characterized in that, The random number generator uses a pseudo-random number generator.

7. The blockchain sharding method according to claim 6, characterized in that, A random oracle is used as the pseudo-random number generator.

8. A blockchain system, characterized in that, It includes a reference committee and a system shard; the reference committee performs sharding reconstruction on the system shard according to any one of claims 1 to 7, wherein the leader node of the system shard is calculated according to any one of claims 1 to 7.

9. A method for processing cross-shard transactions, characterized in that, Applied to the blockchain system of claim 8, the process is executed in the source shard, including: transaction packaging process: the leader node packages the transaction into a block and broadcasts it within the shard; block consensus process: each node votes on the consensus of the received block and broadcasts the voting results; transaction sending process: the leader node sends the block that has passed consensus to the target shard; wherein, the transaction packaging process of the current block and the block consensus process of the previous block are executed in parallel.

10. The cross-shard transaction processing method according to claim 9, characterized in that, The transaction packaging process includes: the leader node packages the transaction into a block, broadcasts the block and block digest within the shard, and the block digest is used to enable nodes within the shard to pre-verify the block.

11. The cross-shard transaction processing method according to claim 9, characterized in that, The block consensus process includes: nodes within a shard receive a block digest after a first time interval and a block after a second time interval; nodes vote on the block consensus and broadcast the voting results within the shard; when more than a set number of nodes agree on the block, the nodes write the block into their local ledger.

12. The cross-shard transaction processing method according to claim 9, characterized in that, The parallel execution process of the method specifically includes: while the leader node packages the transaction into the current block, the nodes in the shard vote on the consensus of the previous block; and while the leader node broadcasts the current block in the shard, the nodes in the shard write the previous block into their local ledger.

13. The cross-shard transaction processing method according to claim 12, characterized in that, The method also includes: the leader node waits for the consensus voting of the previous block to end before encapsulating the current block.

14. The cross-shard transaction processing method according to claim 12, characterized in that, The method further includes: when the leader node receives the broadcast of the previous block, it verifies the previous block and packages the transactions that are mutually exclusive with the transactions in the previous block first.

15. The cross-shard transaction processing method according to claim 9, characterized in that, The transaction packaging process also includes: when the leader node packages a transaction into the current block, it constructs the Merkle root of the transaction and writes it into the block header of the current block.

16. The cross-shard transaction processing method according to claim 15, characterized in that, The process of constructing the Merkle root of a transaction and writing it into the block header of the current block includes: clustering transactions according to the target shard address, sorting transactions sent to the same target shard according to their hash values, constructing Merkle subtrees for transactions sent to the same target shard, merging different Merkle subtrees into a complete Merkle tree, and writing the Merkle root of the Merkle tree into the block header of the current block.

17. The cross-shard transaction processing method according to claim 9, characterized in that, The transaction sending process includes: the leader node sending transactions destined for the same target shard in batches to the corresponding target shard, while simultaneously broadcasting the block header and the roots of all Merkle subtrees.

18. The cross-shard transaction processing method according to claim 10, characterized in that, The block digest includes at least: the sequence number of the current block, the sequence number of the current time slot, the block hash value, and the identity identifier of the leader node.

19. A cross-shard transaction processing method, applied to the blockchain system of claim 8, executed in the target shard, comprising: Receive blocks sent by the source fragment, and verify and execute transactions within the block that belong to this fragment for processing.

20. The cross-shard transaction processing method according to claim 19, characterized in that, The verification of transactions within a block that belong to this shard includes: receiving transactions sent in batches from the source shard; reconstructing the root of the corresponding Merkle subtree based on the hash value of the transaction; reconstructing the Merkle root based on the roots of other Merkle subtrees; comparing the reconstructed Merkle root with the Merkle root in the block header; if they are the same, the transaction is valid and executable; otherwise, the transaction is invalid.

21. The cross-shard transaction processing method according to claim 19, characterized in that, The method further includes: nodes within the target shard verifying whether there is an invalid node signature in the block header based on the shard node table.

22. A blockchain sharding system, characterized in that, It includes a source shard and a target shard; the source shard is used to implement the cross-shard transaction processing method according to any one of claims 9 to 18, and the target shard is used to implement the cross-shard transaction processing method according to any one of claims 19 to 21.

23. An electronic device, characterized in that, It includes a memory and a processor; the memory is used to store a program; the processor is used to execute the program to implement the blockchain sharding method as described in any one of claims 1 to 7, or the cross-shard transaction processing method as described in any one of claims 9 to 18, or the cross-shard transaction processing method as described in any one of claims 19 to 21.

24. 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 7, or the cross-shard transaction processing method as described in any one of claims 9 to 18, or the cross-shard transaction processing method as described in any one of claims 19 to 21.

Images