Flexible sharding blockchain method and device based on cross-shard Byzantine fault-tolerant algorithm

Abstract

The present application discloses a flexible sharding blockchain method and device based on a cross-shard Byzantine fault tolerance algorithm, wherein the method includes: applying a trusted initialization technique, initializing a genesis block, accepting a shard member list and initial data sent by a shard corresponding to a node in the shard list; obtaining multiple transactions within a shard, and sending multiple transactions to a shard-byzantine fault tolerance protocol and a cross-shard Byzantine fault tolerance protocol according to the transaction types of the multiple transactions, so as to process the multiple transactions; writing the processed valid transactions into the blockchain of the output shard, and outputting the intra-shard and cross-shard blockchains, reconfiguring the shard members in the shard member list, so as to generate the blockchain of the next cycle. It has the characteristics of strong scalability, low transaction confirmation delay, high system parallelism, and high security.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a flexible sharding blockchain method and device based on a cross-shard Byzantine fault-tolerant algorithm. Background Art

[0002] Blockchain was first proposed in 2008. As a distributed and tamper-proof underlying ledger, the technology has been widely developed and applied in various fields such as manufacturing, finance, and the Internet of Things in recent years. However, most existing blockchain technology solutions still have deficiencies in throughput, scalability, security, latency, etc., which limits the further implementation of blockchain and its related applications.

[0003] In the context of the above problems, the academic community proposed the concept of sharded blockchain. By combining the sharding technology first proposed in the database field, the underlying network, transactions or states of the blockchain are divided so that the nodes in the shard usually only need to handle the computing, communication and storage requirements of the shard. Sharded blockchain is an important on-chain method for improving the throughput, latency and scalability of blockchain systems. This technology improves the parallel processing degree of nodes in the blockchain network and reduces the transaction processing volume in large-scale transaction processing scenarios.

[0004] Existing research on sharded blockchains focuses on shard configuration, the design of intra-shard consensus algorithms, and cross-shard transaction processing solutions. However, existing research still lacks in the following aspects:

[0005] (1) Cross-shard transaction processing faces the problem of high communication complexity and low efficiency caused by long communication time. Existing solutions such as Omniledger and Chainspace generally use a two-phase commitment protocol to process cross-shard transactions. In the preparation phase, the relevant shards run the Byzantine Fault Tolerance (BFT) algorithm to confirm the legitimacy of the transaction input and send it to all relevant shards, while locking the corresponding unspent transaction output (UTXO); in the commitment phase, all relevant shards run the BFT algorithm to confirm the legitimacy of the transaction, resulting in the need to run two rounds of BFT algorithms and four rounds of voting to commit to the transaction during the formulation process, which increases the transaction confirmation delay.

[0006] (2) The existing system has a low degree of parallelism, and the overall performance is limited by the bandwidth and computing power of the leader.

[0007] (3) Cross-shard security issues caused by incomplete cross-shard message delivery. Since the leader is mainly responsible for forwarding cross-shard transaction messages, nodes within the shard cannot know whether key information is forwarded by the leader. Therefore, a malicious leader may modify cross-shard transactions.

[0008] (4) Existing sharding reconfiguration schemes have the problem of being too centralised. At the same time, most current schemes use complex distributed random number generation protocols, which brings additional high overhead to the system. Summary of the invention

[0009] The present application provides a flexible sharding blockchain method and device based on a cross-shard Byzantine fault-tolerant algorithm, which has the characteristics of strong scalability, low transaction confirmation latency, high system parallelism, and high security.

[0010] The first aspect of the present application provides a flexible sharding blockchain method based on a cross-shard Byzantine fault tolerance algorithm, comprising the following steps: applying a trusted initialization technology to initialize a genesis block, accepting a shard member list and initial data sent by a shard corresponding to a node in the shard list; obtaining multiple transactions within a shard, and sending the multiple transactions to an intra-shard Byzantine fault tolerance protocol and a cross-shard Byzantine fault tolerance protocol according to transaction types of the multiple transactions to process the multiple transactions; writing the processed valid transactions into a blockchain of an output shard, outputting the intra-shard and cross-shard blockchains, and reconfiguring the shard members in the shard member list to generate a blockchain for the next cycle.

[0011] Optionally, in one embodiment of the present application, the multiple transactions are processed through the intra-shard Byzantine fault-tolerant protocol, including: using the leader node to construct a proposal containing all transactions, and sending the proposal to the shard members; the shard members call the PCom protocol to verify the legitimacy of the proposal and vote on the proposal; when the number of legitimate votes is greater than a first preset number, using the leader node to construct a multi-signature and broadcast it; using the shard members to verify the multi-signature and vote to the leader node, determine the legitimate signature according to the voting result, and construct a commitment certificate through the leader node and broadcast it; using the shard members to verify the legitimacy of the commitment certificate, and accept the proposal when the commitment certificate is legitimate.

[0012] Optionally, in one embodiment of the present application, the multiple transactions are processed through the intra-shard Byzantine fault-tolerant protocol, including: constructing and broadcasting a view conversion message through the shard members, sending the view conversion message to the leader node, attaching its own signature, and updating the view state after receiving a confirmation message from the leader node; after receiving a second preset number of the view conversion messages through the leader node, constructing a proposal and commitment proof of the view conversion message, and constructing confirmation information, and broadcasting the confirmation information within the shard after signing.

[0013] Optionally, in one embodiment of the present application, the multiple transactions are processed by the cross-shard Byzantine fault-tolerant protocol, including: constructing a proposal through the leader nodes of all shards and broadcasting it within the shards; verifying the legitimacy of the proposal through the shard members calling PCom, and voting to the leader node for the legal proposal; after the leader node collects a third preset number of legal votes, constructing a multi-signature through the leader node, and forwarding it to the cooperative shard leader node by the relay node; after the cooperative shard leader node collects all the multi-signatures, calculating the aggregate signature, and sending the prepare message and the proof to all relevant shard leader nodes; Generate a proposal through all shard leader nodes and broadcast it within the shard; verify the legitimacy of the proposal by calling PCom through shard members, and vote on legal proposals; after the shard leader node collects a fourth preset number of legal votes, construct a multi-signature and send it to the cooperative shard leader node; after the cooperative shard leader node collects enough messages, calculate the signature, construct a commitment message, and send it to all relevant shard leader nodes; after the shard leader node receives a legal commitment message, broadcast it within the current shard; if the honest node receives a legal commitment message, modify the proposal status and write the corresponding transaction into the relevant blockchain.

[0014] Optionally, in one embodiment of the present application, the multiple transactions are processed through the cross-shard Byzantine fault-tolerant protocol, including: constructing a view conversion message through the shard leader node and broadcasting it in the current shard; after receiving a fifth preset number of legitimate view conversion messages, broadcasting a cross-domain commitment message in the current shard; after receiving a sixth preset number of legitimate cross-domain commitment messages, sending a cross-domain commitment message and an aggregate signature to multiple members of the corresponding shard; after receiving the view conversion message, using the shard members to verify the legitimacy of the message, and sending a signature to the leader node for the legitimate message; after the shard members receive the cross-domain commitment message from the current shard leader node, verify the legitimacy of the message, and send a signature to the leader node for the legitimate message; after the shard members receive the cross-domain commitment message from other shard leader nodes, verify the legitimacy of the message, and if it is legitimate, execute the view conversion within the shard.

[0015] The second aspect of the present application provides a flexible sharding blockchain device based on a cross-shard Byzantine fault tolerance algorithm, including: an initialization module, used to apply a trusted initialization technology, initialize a genesis block, and accept a shard member list and initial data sent by a shard corresponding to a node in the shard list; a processing module, used to obtain multiple transactions within a shard, and send the multiple transactions to an intra-shard Byzantine fault tolerance protocol and a cross-shard Byzantine fault tolerance protocol according to transaction types of the multiple transactions to process the multiple transactions; a generation module, used to write the processed valid transactions into the blockchain of an output shard, and output the intra-shard and cross-shard blockchains, and reconfigure the shard members in the shard member list to generate a blockchain for the next cycle.

[0016] Optionally, in one embodiment of the present application, the processing module is specifically used to use the leader node to construct a proposal containing all transactions, and send the proposal to the shard members; the shard members call the PCom protocol to verify the legitimacy of the proposal and vote on the proposal; when the number of legal votes is greater than a first preset number, use the leader node to construct a multi-signature and broadcast it; use the shard members to verify the multi-signature and vote to the leader node, determine the legal signature according to the voting result, and construct a commitment certificate through the leader node and broadcast it; use the shard members to verify the legitimacy of the commitment certificate, and accept the proposal when the commitment certificate is legal.

[0017] Optionally, in one embodiment of the present application, the processing module is specifically used to construct and broadcast a view conversion message through the shard members, send the view conversion message to the leader node, attach its own signature, and update the view state after receiving a confirmation message from the leader node; after receiving a second preset number of the view conversion messages through the leader node, construct a proposal and commitment certificate of the view conversion message, and construct confirmation information, and broadcast the confirmation information within the shard after signing.

[0018] Optionally, in one embodiment of the present application, the processing module is specifically used to construct a proposal through the leader nodes of all shards and broadcast it within the shard; verify the legitimacy of the proposal by calling PCom through the shard members, and vote for the legal proposal to the leader node; after the leader node collects a third preset number of legal votes, construct a multi-signature through the leader node, and forward it to the cooperative shard leader node by the relay node; after the cooperative shard leader node collects all multi-signatures, calculate the aggregate signature, and send the preparation message and the certificate to all relevant shard leader nodes; generate a proposal through all shard leader nodes and broadcast it within the shard; verify the legitimacy of the proposal by calling PCom through the shard members, and vote for the legal proposal; after the shard leader node collects a fourth preset number of legal votes, construct a multi-signature and send it to the cooperative shard leader node; after the cooperative shard leader node collects enough messages, calculate the signature, construct a commitment message, and send it to all relevant shard leader nodes; after the shard leader node receives a legal commitment message, broadcast it within the current shard; if the honest node receives a legal commitment message, modify the proposal status and write the corresponding transaction into the relevant blockchain.

[0019] Optionally, in one embodiment of the present application, the processing module is specifically used to construct a view conversion message through a shard leader node and broadcast it in the current shard; after receiving a fifth preset number of legitimate view conversion messages, broadcast a cross-domain commitment message in the current shard; after receiving a sixth preset number of legitimate cross-domain commitment messages, send a cross-domain commitment message and an aggregate signature to multiple members of the corresponding shard; after receiving the view conversion message, use the shard members to verify the legitimacy of the message, and send a signature to the leader node for the legitimate message; after the shard member receives the cross-domain commitment message from the current shard leader node, verify the legitimacy of the message, and send a signature to the leader node for the legitimate message; after the shard member receives the cross-domain commitment message from other shard leader nodes, verify the legitimacy of the message, and if it is legitimate, execute the view conversion within the shard.

[0020] The flexible sharding blockchain method and device based on the cross-shard Byzantine fault tolerance algorithm of the present application have the characteristics of strong scalability, low transaction confirmation delay, high system parallelism and high security. The main purpose of the present application is as follows: a cross-shard Byzantine fault tolerance (Cross-Shard BFT, CSBFT) protocol is designed, which reduces the cross-shard transaction processing delay and improves the transaction processing efficiency. By applying multiple parallel cross-shard Byzantine fault tolerance protocols, the node can process transactions as a leader and a member at the same time, breaking the system performance bottleneck caused by the leader node's computing and communication resource limitations, and improving the system's parallelism. A potential cross-shard transaction review attack is proposed, and a cross-shard attempt conversion mechanism is designed for the attack, solving the security pain points of the traditional sharding protocol. Combining the Proof-of-Work consensus mechanism (PoW), the Proof-of-Possession consensus mechanism (PoP) and the BFT consensus mechanism, a completely decentralized sharding reconfiguration method is proposed, which solves the problem of incomplete centralization of the existing reconfiguration scheme without bringing additional high overhead.

[0021] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0023] Figure 1 A flowchart of a flexible sharding blockchain method based on a cross-shard Byzantine fault-tolerant algorithm provided according to an embodiment of the present application;

[0024] Figure 2 A flowchart of a flexible sharding blockchain method based on a cross-shard Byzantine fault tolerance algorithm provided according to an embodiment of the present application;

[0025] Figure 3 A CSBFT protocol timing diagram provided according to an embodiment of the present application;

[0026] Figure 4 An overview diagram of an FS protocol provided according to an embodiment of the present application;

[0027] Figure 5 This is an example diagram of a flexible sharding blockchain device based on a cross-shard Byzantine fault-tolerant algorithm according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0029] Before introducing the flexible sharding blockchain method based on the cross-shard Byzantine fault-tolerant algorithm of this application, the following system assumptions are made:

[0030] Definition 1 (Adversary and Environment Model): The adversary and environment model (A, Z) is (N, Δ, ρ, τ)-restricted with respect to protocol Π if and only if each time EXEC is executed Π(A,Z) The following conditions must be met:

[0031] (1) The total number of participating nodes is N;

[0032] (2) The upper limit of A’s computing power is ρ, and A cannot forge a digital signature;

[0033] (3) The network model is partially synchronous, the ability of adversary A to delay and reorder messages is limited, and all messages can arrive within Δ time;

[0034] (4) Mild corruption: The adversary issues a corruption command to the target node. After τ time, the target node is corrupted.

[0035] The system architecture of this application is as follows:

[0036] Assume that the system contains m shards S 1 ,S 2 ,…,S m , each shard contains n nodes. For each cycle e, in each shard There are m leaders L j1 ,…,L jj ,…,L jm Among them, L j1 Primary and Shard S 1 Communicate and process related transactions. Therefore, in each shard, there are m corresponding chains.

[0037] Figure 1 The present invention is a flowchart of a flexible sharding blockchain method based on a cross-shard Byzantine fault-tolerant algorithm provided according to an embodiment of the present application.

[0038] like Figure 1 As shown, the flexible sharding blockchain method based on the cross-shard Byzantine fault tolerance algorithm includes the following steps:

[0039] In step S101, the trusted initialization technology is applied to initialize the genesis block, and the shard member list and the initial data sent by the shard corresponding to the node in the shard list are received.

[0040] Combination Figure 2 , Figure 3 and Figure 4 As shown, the flexible sharding protocol Π FS Including using PoW for node election and using Π ISBFT Perform shard reconfiguration using Π ISBFT Processing intra-shard transactions and using PI CSBFT Processing cross-shard transactions. The general process of the flexible sharding protocol is described as follows:

[0041] Phase 1: Initialization

[0042] Step 1: Π FS The startup relies on trusted initialization technology, where honest nodes account for more than 2 / 3 of the m shards. At the same time, a genesis block will be initialized in each shard.

[0043] Phase 2: Cycle Start

[0044] Step 2: In cycle e, each node will receive shard S j List of shard members

[0045] Step 3: If a node's public key is in the above list, the node will receive S in the e-1th cycle. j UTXO sent by fragment j With S j Sharded local blockchain C j1 ,…,C jm .

[0046] Step 4: After that, the node sends a start instruction start to the instance ISBFT[e] of the intra-shard Byzantine fault tolerance protocol and the instance CSBFT[e] of the cross-shard Byzantine fault tolerance protocol.

[0047] In step S102, multiple transactions within the shard are obtained, and according to the transaction types of the multiple transactions, the multiple transactions are sent to the intra-shard Byzantine fault tolerance protocol and the cross-shard Byzantine fault tolerance protocol to process the multiple transactions.

[0048] Based on the above embodiment, Phase 3: Transaction Processing

[0049] Step 5: From the environment After obtaining TXs from , convert them into TX in With TX cross Classification.

[0050] Step 6: After this, TX in With TX cross Input ISBFT[e] and CSBFT[e] respectively, and process the transaction.

[0051] Step 7: If For an output shard, write the valid transaction to of blockchain.

[0052] Step 8: After a period of time, ISBFT[e] and CSBFT[e] finally output the blockchain <C jj >With <C jc >.

[0053] In step S103, the processed valid transactions are written into the blockchain of the output shard, and the intra-shard and cross-shard blockchains are output, and the shard members in the shard member list are reconfigured to generate the blockchain of the next cycle.

[0054] Based on the above embodiment, Phase 4: Slice Reconfiguration

[0055] Step 9: Each shard acts as a reference committee and updates its shard members in order. Nodes that want to join the shard in the next cycle should find a solution to the PoW problem. The public key pk of the node is required in the mining process. i , to prevent the adversary from maliciously using PoW to commit fraud. At the same time, the node’s public key proves π i As PoP, it is sent together with the solution of the legitimate PoW to prevent public key ambiguity attacks.

[0056] Step 10: Legal PK i Will be added to the shard member list. When the number of nodes is n, As input to ISBFT[e].

[0057] Step 11: The leader runs ISBFT with the shard members and applies threshold voting technology to confirm the list.

[0058] Step 12: ISBFT finally outputs the approved

[0059] Step 13: FS issues a stop command to ISBFT and CSBFT.

[0060] Step 14: Broadcast in the network so that each node knows whether it is At this time S j The period e ends and the period e+1 begins.

[0061] The complete process of the flexible sharding protocol can be described as follows:

[0062]

[0063] Optionally, in one embodiment of the present application, multiple transactions are processed through an intra-shard Byzantine fault-tolerant protocol, including: using a leader node to construct a proposal containing all transactions, and sending the proposal to shard members; using shard members to call the PCom protocol to verify the legitimacy of the proposal and vote on the proposal; when the number of legitimate votes is greater than a first preset number, using the leader node to construct a multi-signature and broadcast it; using shard members to verify the multi-signature and vote for the leader node, determine the legitimate signature based on the voting results, and construct a commitment certificate through the leader node and broadcast it; using shard members to verify the legitimacy of the commitment certificate, and accept the proposal when the commitment certificate is legitimate.

[0064] Optionally, in one embodiment of the present application, multiple transactions are processed through a Byzantine fault-tolerant protocol within a shard, including: constructing and broadcasting a view conversion message through a shard member, sending the view conversion message to a leader node, attaching its own signature, and updating the view state after receiving a confirmation message from the leader node; after receiving a second preset number of view conversion messages through the leader node, constructing a proposal and commitment proof of the view conversion message, and constructing confirmation information, and broadcasting the confirmation information within the shard after signing.

[0065] The entire agreement of this application is FS =(FS,Π ISBFT ,Π CSBFT ) represents, where FS includes node election and periodic reconfiguration process, Π ISBFT Including intra-shard transaction processing and shard member list confirmation process in the new cycle, Π CSBFT It is used to process cross-shard transactions.

[0066] This application improves the multi-signature aggregation technology (BLS Multi-Signature, BLSMS), and adds a KeyVer interface for verifying the legitimacy of the public key and resisting fuzzy public key attacks on the basis of the original scheme; at the same time, this application provides a share verification interface SVer and a multi-signature verification interface MVer that can provide robustness. The multi-signature aggregation scheme used in this application needs to meet the following three characteristics.

[0067] 1. Unforgeability: An adversary cannot forge a signature share, multiple signatures, or an aggregate signature;

[0068] 2. Robustness: The adversary cannot prevent the generation of a legitimate multi-signature;

[0069] 3. Satisfy the threshold number t=2f+1.

[0070] BLSMS can be well adapted to Π FS , where the signature share s is generated by the participating nodes, the multi-signature σ is used as a commitment proof, generated by 2f+1 signature shares, and the p multi-signatures of the relevant shards can be aggregated into a complete signature ∑ when processing cross-shard transactions.

[0071]

[0072]

[0073] Intra-shard Byzantine Fault Tolerance Protocol Π ISBFT It consists of three sub-protocols: PCom, ISBFT and ISVC.

[0074] The subprotocol PCom is used by shard leaders and shard members to calculate the value of the proposal and is used by protocol Π ISBFT For processing TX in .

[0075]

[0076]

[0077] The subprotocol ISBFT describes the normal operation of the intra-shard Byzantine fault-tolerant protocol. At the beginning of each cycle, the FS input ISBFT starts to execute. The main steps are described as follows:

[0078] 1. The leader structure contains all transaction TX in Proposal P v,r , and m ip Send to shard members;

[0079] 2. Shard members receive m ip After that, it verifies the legitimacy of the proposal by calling PCom. If it is legitimate, it votes for the shard leader.

[0080] 3. If the leader collects 2f+1 legal votes, a multi-signature σ is constructed ip , and broadcast m ic ;

[0081] 4. Shard member verification m ic and vote for the leader;

[0082] 5. If the leader collects 2f+1 valid votes, it constructs and broadcasts a commitment proof σ ic ;

[0083] 6. Shard Membership Verificationσ ic The validity of the corresponding proposal Pv,r Deemed accepted by the blockchain.

[0084] The complete protocol is described below:

[0085]

[0086]

[0087]

[0088] The sub-protocol intra-shard view conversion ISVC is mainly used to prevent the leader from going offline or making malicious behaviors, and to give the honest nodes in the shard the ability to replace the malicious leader. The protocol flow is described as follows:

[0089]

[0090]

[0091] Cross-shard Byzantine Fault Tolerant Protocol Π CSBFT It consists of four sub-protocols: CSBFT, CSVC, ISVC and PCom.

[0092] The sub-protocol CSBFT receives start and end instructions from FS and processes cross-chip transactions TX cross The general process of CSBFT can be described as follows:

[0093] Phase 1: Cross-domain preparation

[0094] Step 1: All shard leaders compute proposals via PCom according to Structure m cp , and broadcast in each shard, where b i Indicates whether the input of the shard is legal.

[0095] Step 2: When receiving a valid m cp After that, the honest node calls PCom to verify the leader's whether it is legal, and vote with the leader on legal proposals.

[0096] Step 3: After collecting 2f+1 valid votes, the leader constructs a multi-signature in each shard and will Send to L cj . Shard S j Leader in L jc You can forward the message directly to L cj , and the shard S j′ Leader in L j′c Need to send message to L cj′, and forwarded to L cj .

[0097] Step 4: L cj Collect all p related Calculate the aggregate signature∑ cp , and will prepare the message and its proof (M prep ,∑ cp ) is sent to the leaders of all relevant shards.

[0098] Phase 2: Cross-domain commitment phase

[0099] Step 1: All shard leaders call PCom to generate proposals Different from Contains information indicating whether the transaction tx is valid {tx i |B i} |q| Each shard leader constructs m cc And broadcast within the shard.

[0100] Step 2: When receiving a valid m cc After that, the honest node verifies the leader’s Is it legal? If so, vote for the leader.

[0101] Step 3: After collecting 2f+1 valid votes, each shard leader constructs And with m cc Send to L cj .

[0102] Step 4: L cj Collect p legal Calculate signature∑ cc , construct a commitment message M com , and sends it to the p relevant shard leaders.

[0103] Step 5: Each shard leader receives a valid (M com ,∑ cc ) and broadcast it in the current shard.

[0104] Step 6: Each honest node receives a valid (M com ,∑ cc ),Will The status of is set to committed. As an output shard of a legal tx, the shard member writes tx to its related blockchain C jc As the input shard of the legal tx, each node spends the corresponding input of tx. Finally, the recognized blockchain <C jc >(or <Cjc >、 <C j′c >) is output to environment Z.

[0105] The complete protocol flow of CSBFT can be described as follows:

[0106]

[0107]

[0108]

[0109]

[0110] In the above protocol, a malicious shard leader may launch a cross-shard transaction censorship attack, which is defined as follows:

[0111] Definition 2 (cross-shard transaction censorship attack): Let tx p =(I 1 ,…,I p ) as a cross-shard transaction, where I j (j∈[1,p])∈S j Let L jc For fragment S j If L jc In S j Acting honestly in the shard and sending an invalid commitment proof in the relevant shard, or not forwarding the commitment proof Then L jc It can be judged that a cross-shard transaction censorship attack has been launched.

[0112] The sub-protocol CSVC is mainly used to defend against cross-shard transaction censorship attacks. The complete protocol process is as follows:

[0113]

[0114]

[0115] Intra-shard transactions are performed by L jj Running Protocol Π ISBFT Processing, Π ISBFT It includes the intra-shard BFT algorithm ISBFT (Intra-Shard BFT) for processing routine operations and the intra-shard view-change algorithm ISVC (Intra-Shard View-Change) for processing intra-shard transactions. CSBFTThe system uses a cross-shard BFT algorithm, CSBFT (Cross-Shard BFT), to handle routine operations. In order to solve the problem that a shard leader may be honest within its shard but have malicious behavior in cross-shard transactions, a cross-shard view conversion algorithm, CSVC (Cross-Shard View-Change), is proposed to replace malicious leaders. Transactions input into the system are assigned to different shards and leaders according to special rules. Represents a TX managed by p shards and containing q transactions. Each transaction corresponds to a certain coordination leader L cj , a direct leader L jc and p-2 indirect leaders L j′c .

[0116] In order to improve the parallelism of the system, this application uses multiple parallel CSBFT to process transactions. Among them, the node not only acts as the leader of the CSBFT instance, but also participates in multiple parallel CSBFT as an ordinary member. By adopting this architecture, the leader's computing and communication overhead is distributed to multiple members in the shard, breaking the performance bottleneck caused by the leader's limited bandwidth and computing resources.

[0117] During the shard reconfiguration process, in each cycle e, each shard Each of them serves as a reference committee, receives the solution to the PoW problem, and runs the ISBFT algorithm in combination with the threshold voting rule to confirm the member list for the next cycle. The reconfiguration process is performed one by one between the slices. After reconfiguration is complete, Start the process.

[0118] According to the flexible sharding blockchain method based on the cross-shard Byzantine fault-tolerant algorithm proposed in the embodiment of the present application, the flexible sharding blockchain method breaks the technical bottleneck of the traditional method being limited by the leader's computing and communication resources. By enabling each node to participate in multiple parallel CSBFTs and act as a leader and an ordinary member at the same time, the present application improves the throughput of the sharded blockchain and reduces the system latency. The flexible sharding blockchain method reduces the complexity of cross-shard communication. Multiple shards jointly run the CSBFT protocol, reducing the 4 rounds of voting in the traditional cross-shard protocol to 2 rounds, greatly reducing the system communication complexity and latency. The flexible sharding blockchain method has high security. In response to potential cross-shard transaction review attacks in sharded blockchains, the present application designs a cross-shard view conversion mechanism, which greatly improves the system's ability to resist attacks.

[0119] Secondly, a flexible sharding blockchain device based on a cross-shard Byzantine fault-tolerant algorithm proposed according to an embodiment of the present application is described with reference to the accompanying drawings.

[0120] Figure 5 This is an example diagram of a flexible sharding blockchain device based on a cross-shard Byzantine fault-tolerant algorithm according to an embodiment of the present application.

[0121] like Figure 5 As shown, the flexible sharding blockchain device 10 based on the cross-shard Byzantine fault tolerance algorithm includes: an initialization module 100, a processing module 200 and a generation module 300.

[0122] Among them, the initialization module 100 is used to apply the trusted initialization technology, initialize the genesis block, and accept the initial data sent by the shard member list and the shard corresponding to the node in the shard list. The processing module 200 is used to obtain multiple transactions in the shard, and according to the transaction types of the multiple transactions, send the multiple transactions to the intra-shard Byzantine fault tolerance protocol and the cross-shard Byzantine fault tolerance protocol to process the multiple transactions. The generation module 300 is used to write the processed valid transactions into the blockchain of the output shard, and output the intra-shard and cross-shard blockchains, reconfigure the shard members in the shard member list to generate the blockchain of the next cycle.

[0123] Optionally, in one embodiment of the present application, the processing module is specifically used to use the leader node to construct a proposal containing all transactions, and send the proposal to the shard members; verify the legitimacy of the proposal by calling the PCom protocol through the shard members and vote on the proposal; when the number of legal votes is greater than a first preset number, use the leader node to construct a multi-signature and broadcast it; use the shard members to verify the multi-signature and vote to the leader node, determine the legal signature according to the voting results, construct a commitment certificate through the leader node and broadcast it; use the shard members to verify the legitimacy of the commitment certificate, and accept the proposal when the commitment certificate is legal.

[0124] Optionally, in one embodiment of the present application, the processing module is specifically used to construct and broadcast a view conversion message through shard members, send the view conversion message to the leader node, attach its own signature, and update the view state after receiving a confirmation message from the leader node; after receiving a second preset number of view conversion messages through the leader node, construct a proposal and commitment proof of the view conversion message, and construct confirmation information, and broadcast the confirmation information within the shard after signing.

[0125] Optionally, in one embodiment of the present application, the processing module is specifically used to construct a proposal through the leader nodes of all shards and broadcast it within the shard; verify the legitimacy of the proposal by calling PCom through the shard members, and vote for the legal proposal to the leader node; after the leader node collects a third preset number of legal votes, construct a multi-signature through the leader node, and forward it to the cooperative shard leader node by the relay node; after the cooperative shard leader node collects all multi-signatures, calculate the aggregate signature, and send the preparation message and the certificate to all relevant shard leader nodes; generate a proposal through all shard leader nodes and broadcast it within the shard; verify the legitimacy of the proposal by calling PCom through the shard members, and vote for the legal proposal; after the shard leader node collects a fourth preset number of legal votes, construct a multi-signature and send it to the cooperative shard leader node; after the cooperative shard leader node collects enough messages, calculate the signature, construct a commitment message, and send it to all relevant shard leader nodes; after the shard leader node receives a legal commitment message, broadcast it within the current shard; if the honest node receives a legal commitment message, modify the proposal status and write the corresponding transaction into the relevant blockchain.

[0126] Optionally, in one embodiment of the present application, the processing module is specifically used to construct a view conversion message through a shard leader node and broadcast it in the current shard; after receiving a fifth preset number of legitimate view conversion messages, broadcast a cross-domain commitment message in the current shard; after receiving a sixth preset number of legitimate cross-domain commitment messages, send a cross-domain commitment message and an aggregate signature to multiple members of the corresponding shard; after receiving the view conversion message, use the shard members to verify the legitimacy of the message, and send a signature to the leader node for the legitimate message; after the shard member receives the cross-domain commitment message from the current shard leader node, verify the legitimacy of the message, and send a signature to the leader node for the legitimate message; after the shard member receives the cross-domain commitment message from other shard leader nodes, verify the legitimacy of the message, and if it is legitimate, execute the view conversion within the shard.

[0127] It should be noted that the aforementioned explanation of the embodiment of the flexible sharded blockchain method based on the cross-sharded Byzantine fault-tolerant algorithm is also applicable to the flexible sharded blockchain device based on the cross-sharded Byzantine fault-tolerant algorithm of this embodiment, and will not be repeated here.

[0128] According to the flexible sharding blockchain device based on the cross-shard Byzantine fault-tolerant algorithm proposed in the embodiment of the present application, the flexible sharding blockchain method breaks the technical bottleneck of the traditional method being limited by the leader's computing and communication resources. By enabling each node to participate in multiple parallel CSBFTs and act as a leader and an ordinary member at the same time, the present application improves the throughput of the sharded blockchain and reduces the system latency. The flexible sharding blockchain method reduces the complexity of cross-shard communication. Multiple shards jointly run the CSBFT protocol, reducing the 4 rounds of voting in the traditional cross-shard protocol to 2 rounds, greatly reducing the system communication complexity and latency. The flexible sharding blockchain method has high security. In response to potential cross-shard transaction review attacks in sharded blockchains, the present application designs a cross-shard view conversion mechanism, which greatly improves the system's ability to resist attacks.

[0129] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0130] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0131] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

Claims

1. A flexible sharding blockchain method based on a cross-shard Byzantine fault-tolerant algorithm, characterized in that: The following steps are involved: Apply the trusted initialization technology to initialize the genesis block, accept the shard member list and the initial data sent by the shard corresponding to the node in the shard member list; Acquire multiple transactions within a shard, and send the multiple transactions to an intra-shard Byzantine fault tolerance protocol and a cross-shard Byzantine fault tolerance protocol according to transaction types of the multiple transactions to process the multiple transactions, wherein: Processing the multiple transactions through the intra-shard Byzantine fault-tolerant protocol includes: Use the leader node to construct a proposal containing all transactions and send the proposal to the shard members; The shard members call the PCom protocol to verify the legitimacy of the proposal and vote on the proposal; When the number of legal votes is greater than a first preset number, constructing a multi-signature using the leader node and broadcasting it; Using the shard members to verify the multi-signature and vote for the leader node, determining the legal signature based on the voting results, constructing and broadcasting the commitment certificate through the leader node; Verify the legitimacy of the commitment certificate using the shard members, and accept the proposal when the commitment certificate is legitimate; Write the processed valid transactions into the blockchain of the output shard, output the intra-shard and cross-shard blockchains, and reconfigure the shard members in the shard member list to generate the blockchain of the next cycle.

2. The method according to claim 1, characterized in that Processing the multiple transactions through the intra-shard Byzantine fault-tolerant protocol includes: The shard member constructs and broadcasts a view conversion message, sends the view conversion message to the leader node, and adds its own signature, and updates the view state after receiving a confirmation message from the leader node; After receiving the second preset number of view conversion messages through the leader node, a proposal and commitment proof of the view conversion message are constructed, and confirmation information is constructed, and the confirmation information is broadcasted in the shard after signing.

3. The method according to claim 1, characterized in that Processing the multiple transactions through the cross-shard Byzantine fault-tolerant protocol includes: The proposal is constructed through the leader nodes of all shards and broadcast within the shards; The shard members call PCom to verify the legitimacy of the proposal and vote with the leader node on the legal proposal; After the leader node collects a third preset number of legal votes, a multi-signature is constructed through the leader node and forwarded to the leader node of the cooperating shard by the relay node; After the cooperating shard leader node collects all multi-signatures, it calculates the aggregate signature and sends the prepare message and proof to all relevant shard leader nodes; Generate proposals through all shard leader nodes and broadcast them within the shard; Shard members call PCom to verify the legitimacy of the proposal and vote on legitimate proposals; After the shard leader node collects the fourth preset number of legal votes, it constructs a multi-signature and sends it to the cooperating shard leader nodes; After the cooperating shard leader nodes have collected enough messages, they calculate the signature and construct a commitment message, which is sent to all relevant shard leader nodes; After the shard leader node receives a valid commitment message, it broadcasts it within the current shard; If an honest node receives a legitimate commitment message, it modifies the proposed state and writes the corresponding transaction into the relevant blockchain.

4. The method according to claim 3, characterized in that Processing the multiple transactions through the cross-shard Byzantine fault-tolerant protocol includes: The shard leader node constructs a view conversion message and broadcasts it within the current shard; After receiving a fifth preset number of legal view switch messages, broadcasting a cross-domain commitment message in the current shard; After receiving a sixth preset number of legitimate cross-domain commitment messages, sending the cross-domain commitment message and the aggregate signature to multiple members of the corresponding shard; After receiving the view conversion message, use the shard members to verify the legitimacy of the message and send a signature to the leader node for the legitimate message; After receiving the cross-domain commitment message from the current shard leader node, the shard member verifies the legitimacy of the message and sends a signature to the leader node for the legitimate message; After a shard member receives a cross-domain commitment message from another shard leader node, it verifies the legitimacy of the message. If it is legitimate, it executes the intra-shard view conversion.

5. A flexible sharding blockchain device based on a cross-shard Byzantine fault-tolerant algorithm, characterized in that: include: An initialization module, used to apply a trusted initialization technique, initialize the genesis block, and receive a shard member list and initial data sent by the shard corresponding to the node in the shard member list; A processing module is used to obtain multiple transactions within a shard, and send the multiple transactions to the intra-shard Byzantine fault tolerance protocol and the cross-shard Byzantine fault tolerance protocol according to the transaction types of the multiple transactions, so as to process the multiple transactions, wherein the processing module is specifically used to: Use the leader node to construct a proposal containing all transactions and send the proposal to the shard members; The shard members call the PCom protocol to verify the legitimacy of the proposal and vote on the proposal; When the number of legal votes is greater than a first preset number, constructing a multi-signature using the leader node and broadcasting it; Using the shard members to verify the multi-signature and vote for the leader node, determining the legal signature based on the voting results, constructing and broadcasting the commitment certificate through the leader node; Verify the legitimacy of the commitment certificate using the shard members, and accept the proposal when the commitment certificate is legitimate; The generation module is used to write the processed valid transactions into the blockchain of the output shard, output the intra-shard and cross-shard blockchains, and reconfigure the shard members in the shard member list to generate the blockchain of the next cycle.

6. The device according to claim 5, characterized in that The processing module is specifically used for: The shard member constructs and broadcasts a view conversion message, sends the view conversion message to the leader node, and adds its own signature, and updates the view state after receiving a confirmation message from the leader node; After receiving the second preset number of view conversion messages through the leader node, a proposal and commitment proof of the view conversion message are constructed, and confirmation information is constructed, and the confirmation information is broadcasted in the shard after signing.

7. The device according to claim 5, characterized in that The processing module is specifically used for: The proposal is constructed through the leader nodes of all shards and broadcast within the shards; The shard members call PCom to verify the legitimacy of the proposal and vote with the leader node on the legal proposal; After the leader node collects a third preset number of legal votes, a multi-signature is constructed through the leader node and forwarded to the leader node of the cooperating shard by the relay node; After the cooperating shard leader node collects all multi-signatures, it calculates the aggregate signature and sends the prepare message and proof to all relevant shard leader nodes; Generate proposals through all shard leader nodes and broadcast them within the shard; Shard members call PCom to verify the legitimacy of the proposal and vote on legitimate proposals; After the shard leader node collects the fourth preset number of legal votes, it constructs a multi-signature and sends it to the cooperating shard leader nodes; After the cooperating shard leader nodes have collected enough messages, they calculate the signature and construct a commitment message, which is sent to all relevant shard leader nodes; After the shard leader node receives a valid commitment message, it broadcasts it within the current shard; If an honest node receives a legitimate commitment message, it modifies the proposed state and writes the corresponding transaction into the relevant blockchain.

8. The device according to claim 7, characterized in that The processing module is specifically used to: The shard leader node constructs a view conversion message and broadcasts it within the current shard; After receiving a fifth preset number of legal view switch messages, broadcasting a cross-domain commitment message in the current shard; After receiving a sixth preset number of legitimate cross-domain commitment messages, sending the cross-domain commitment message and the aggregate signature to multiple members of the corresponding shard; After receiving the view conversion message, use the shard members to verify the legitimacy of the message and send a signature to the leader node for the legitimate message; After receiving the cross-domain commitment message from the current shard leader node, the shard member verifies the legitimacy of the message and sends a signature to the leader node for the legitimate message; After a shard member receives a cross-domain commitment message from another shard leader node, it verifies the legitimacy of the message. If it is legitimate, it executes the intra-shard view conversion.

Images