An asynchronous blockchain sharding system

Abstract

The application discloses an asynchronous blockchain sharding system and relates to the field of blockchains. In the system, the application layer is used for constructing a transaction model according to transaction information submitted by a user, storing user transactions and regularly inputting the user transactions into a consensus layer for consensus; the consensus layer is used for determining an intra-shard transaction consensus protocol and a cross-shard transaction consensus protocol based on a HoneyBadgerBFT protocol and performing consensus on the transactions; and the data storage layer is used for storing the user transactions in a directed acyclic graph ledger. The application can support cross-shard transactions and parallel execution of transactions.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchain, in particular to an asynchronous blockchain sharding system. BACKGROUND

[0002] Blockchain technology is a new multi-field fusion technology, which solves the trust problem between multiple nodes in traditional information systems, and the data recorded on the blockchain is secure and tamper-proof. However, the blockchain also has the disadvantages of low system throughput, slow data confirmation, and serial transaction processing, which limits its application scenarios. In addition, each node of the blockchain needs to save the full amount of data, which increases the node operation and maintenance cost. In view of these problems, a number of ideas for improving the performance and capacity of the blockchain system have been proposed, such as sharding, off-chain storage and other methods.

[0003] The common permissioned chain sharding system adopts BFT (Byzantine Fault Tolerance) type protocol for transaction consensus, removes the mining part, and ensures data consistency through multiple rounds of communication between nodes. This type of solution has some drawbacks. First, the consensus protocol is only suitable for high-demand network environments, and the system activity is based on a timing assumption, which cannot adapt to a purely asynchronous network environment. Second, the network size of the traditional BFT consensus protocol is limited, and as the number of nodes in the system network increases, the efficiency of the consensus protocol will decrease, which also becomes a performance bottleneck in these sharding solutions.

[0004] In view of the above problems of blockchain expansion and performance, it is urgent to provide a new type of permissioned blockchain sharding system that can run based on a purely asynchronous network environment while improving the capacity of the blockchain system and solving the communication performance bottleneck problem caused by the increase of nodes. SUMMARY

[0005] The purpose of the present application is to provide an asynchronous blockchain sharding system that can support cross-shard transactions and parallel execution of transactions.

[0006] To achieve the above purpose, the present application provides the following solutions:

[0007] An asynchronous blockchain sharding system, comprising: an application layer, a consensus layer and a data storage layer;

[0008] The application layer is used to construct a transaction model according to the transaction information submitted by the user, and store the user transaction and input the user transaction to the consensus layer for consensus at regular intervals;

[0009] The consensus layer is used to determine the intra-shard transaction consensus protocol and cross-shard transaction consensus protocol based on the HoneyBadgerBFT protocol, and to perform consensus on the transactions;

[0010] The data storage layer is configured to store user transactions in a directed acyclic graph ledger.

[0011] Optionally, the application layer comprises a user interface, a transaction model, and a transaction pool.

[0012] The user interface is configured to enable user interaction with the asynchronous blockchain sharding system.

[0013] The transaction model is a data structure for processing transactions.

[0014] The transaction pool is configured to store user transactions and periodically input user transactions to the consensus layer for consensus.

[0015] Optionally, the user interface is a web interface.

[0016] Optionally, the process of intra-shard transaction consensus is as follows:

[0017] In the startup phase, private keys are assigned to each node within the shard, and public keys are established between nodes.

[0018] The node encrypts the locally saved intra-shard transaction using a threshold encryption algorithm to generate ciphertext.

[0019] The node broadcasts the ciphertext and establishes a binary transaction table; the binary transaction table is a key-value pair, with a unique key name used to identify the node, and a value of 0 or 1 used to indicate whether to accept the transaction proposal of the node.

[0020] The nodes between each other reach consensus according to the received ciphertext proposal and the binary transaction table.

[0021] According to the binary transaction table after consensus, the received transaction proposals are combined and decrypted using a threshold decryption algorithm to recover the original transaction data, which is then verified and de-duplicated. After executing the transaction, the data is chained, and the intra-shard transaction is removed from the transaction pool.

[0022] Optionally, the process of cross-shard transaction consensus is as follows:

[0023] In the startup phase, private keys are assigned to nodes within the shard that will perform cross-shard transactions, and public keys are established between nodes.

[0024] Nodes from different shards select cross-shard transactions as proposals from their respective transaction pools, encrypt the transactions using threshold encryption to generate ciphertext.

[0025] The nodes broadcast the ciphertext and establish a binary transaction table.

[0026] The nodes between each other reach consensus according to the received ciphertext proposal and the binary transaction table.

[0027] According to the binary transaction table after the consensus, the received transaction proposal is combined, threshold decryption is used, the original transaction data is recovered, and the de-duplication is verified; after the transaction is executed, the data is chained, and the cross-slice transaction is removed from the transaction pool.

[0028] Optionally, the data storage layer comprises: a ledger structure and a block structure.

[0029] The intra-slice transaction in the ledger structure is directly saved in the local shard; the cross-slice transaction is saved in the shard involved in the corresponding user transaction.

[0030] The block structure comprises: a block for saving cross-slice transactions and a block for saving intra-slice transactions.

[0031] According to the specific embodiments provided by the application, the following technical effects are disclosed.

[0032] The asynchronous blockchain sharding system provided by the application adopts the HoneyBadgerBFT consensus protocol to adapt to a pure asynchronous network environment, adopts a directed acyclic graph (DAG) ledger, enables transactions between different shards to be executed in parallel, and also designs an efficient cross-slice transaction protocol to support inter-shard transactions. The system has data consistency, anti-censorship, and a significant improvement in capacity and performance compared to traditional permissioned blockchains. BRIEF DESCRIPTION OF DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed in the embodiments. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0034] Figure 1 A schematic diagram of the asynchronous blockchain sharding system structure provided by the application;

[0035] Figure 2 A schematic diagram of the asynchronous blockchain sharding system flow provided by the application. DETAILED DESCRIPTION

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

[0037] The application aims to provide an asynchronous blockchain sharding system capable of supporting cross-shard transactions and parallel transaction execution.

[0038] In order to make the above-mentioned purposes, features and advantages of the application more obvious and easy to understand, the application will be further described in detail below in combination with the drawings and specific embodiments.

[0039] As Figure 1 shown, the asynchronous blockchain sharding system provided by the application comprises an application layer, a consensus layer and a data storage layer; the application layer, the consensus layer and the data storage layer are arranged from top to bottom.

[0040] The application layer is configured to construct a transaction model according to transaction information submitted by a user, store user transactions and input the user transactions to the consensus layer for consensus at regular intervals.

[0041] The consensus layer is configured to determine an intra-shard transaction consensus protocol and a cross-shard transaction consensus protocol based on a HoneyBadgerBFT protocol and perform consensus on transactions.

[0042] The data storage layer is configured to store user transactions in a directed acyclic graph ledger.

[0043] The application layer comprises a user interface, a transaction model and a transaction pool.

[0044] The user interface is configured to interact with the asynchronous blockchain sharding system; the user interface is a Web interface.

[0045] The transaction model is a data structure for processing transactions; specifically, the transaction model is an account model, and a user can use the system through an account and also use the account as his / her own identity.

[0046] The transaction pool is configured to store user transactions and input the user transactions to the consensus layer for consensus at regular intervals; the transaction pool also has a certain persistence capability, and when the system is restarted after a failure, the transactions in the transaction pool will not be lost.

[0047] The HoneyBadgerBFT protocol reaches consensus in a purely asynchronous network environment and does not rely on timing assumptions.

[0048] According to the type of transaction, an intra-shard transaction consensus layer or a cross-shard transaction consensus layer is called; the caller first needs to propose part of the transactions to be consensus, then encrypt the transactions, take the encrypted transaction ciphertext as the input of an asynchronous common subset (ACS) consensus layer, wait for the ACS to output a set of decrypted ciphertexts that have been consensus by nodes, and then combine the set of ciphertexts to output a transaction block.

[0049] The process of intra-shard transaction consensus is as follows:

[0050] In the starting phase, private keys are allocated to each node in the shard, and public keys are established between nodes.

[0051] The node selects the intra-shard transaction saved locally, and uses a threshold encryption algorithm to encrypt the transaction to generate ciphertext.

[0052] The node broadcasts the ciphertext and establishes a binary transaction table; the binary transaction table is a key-value pair, the key name is unique, and is used to identify the node; the value is 0 and 1, and is used to indicate whether to accept the transaction proposal of the node.

[0053] The nodes perform consensus according to the received ciphertext proposal and the binary transaction table.

[0054] According to the binary transaction table after consensus, the received transaction proposals are combined, threshold decryption is used to restore the original transaction data, and then the transaction is verified and de-duplicated; after executing the transaction, the data is chained, and the intra-shard transaction is removed from the transaction pool.

[0055] The process of cross-shard transaction consensus is as follows:

[0056] In the starting phase, private keys are allocated to nodes in the shard that will perform cross-shard transactions, and public keys are established between nodes.

[0057] The nodes of different shards select cross-shard transactions as proposals from their respective transaction pools, encrypt the transactions using threshold encryption, and generate ciphertext.

[0058] The node broadcasts the ciphertext and establishes a binary transaction table.

[0059] The nodes perform consensus according to the received ciphertext proposal and the binary transaction table.

[0060] According to the binary transaction table after consensus, the received transaction proposals are combined, threshold decryption is used to restore the original transaction data, and then the transaction is verified and de-duplicated; after executing the transaction, the data is chained, and the cross-shard transaction is removed from the transaction pool.

[0061] The data storage layer is used to persist transaction data, and includes a ledger structure and a block structure.

[0062] Intra-shard transactions are directly saved in the shard in the ledger structure; cross-shard transactions are saved in the shards involved in the user transactions; viewed from the intra-shard perspective, it is still a blockchain, and viewed from the global perspective, the topology structure between blockchains is a directed acyclic graph (DAG).

[0063] The block structure includes blocks for saving cross-shard transactions and blocks for saving intra-shard transactions. Cross-shard blocks need to be saved in each shard, and intra-shard blocks only need to be saved in the current shard.

[0064] In a specific embodiment, the blockchain sharding system is deployed on a blockchain research experimental platform composed of 60 servers of the model of HUAWEI SA5212H5, two Intel_Xeon_Gold6230 CPUs, 384 GB of memory, and 8T of hard disk. The platform includes a blockchain cloud platform, a blockchain IDE integrated development environment, and a blockchain experimental test comprehensive service platform, supports research and development, deployment, testing, and operation and maintenance of various blockchain systems, and has deployed mainstream blockchain systems at home and abroad for research, experiment, and test. The network environment is an enterprise-level network environment.

[0065] As shown in Figure 2 , it includes a user interface, a transaction model, a transaction pool, a consensus layer, and a data storage layer. After the system is initialized, it starts to provide services to the outside. The user inputs transaction information to the system through the user interface, the transaction model formats the transaction information, the transaction pool saves the formatted transactions and periodically inputs the transactions to the consensus layer for consensus, the system internally reaches an agreement on transaction data through the consensus layer, and finally saves the data through the data storage layer, while the transaction pool deletes the transactions that have completed the consensus.

[0066] The system initialization module of the blockchain system has the following steps:

[0067] Setup. Set the intra-shard threshold value t, assign private keys ISK to each node, and calculate the intra-shard public key IPK. The intra-shard nodes that want to perform cross-shard transactions set the threshold value T, assign private keys SK to each node, and produce a set of cross-shard transaction public keys {PK}.

[0068] The user interface module is as follows:

[0069] Submit(from,to,amount). from is the address of the transaction initiator, to is the address of the transaction acceptor, and amount is the transaction amount. The user submits the transaction interface, and after submission, the system formats the data and stores it in the transaction pool.

[0070] Query(address). address can be a block address, a transaction address, or a user address. The query operation results corresponding to different addresses are block information, transaction information, and user historical transaction information, respectively.

[0071] The consensus layer of the blockchain system using the HoneyBadgerBFT consensus algorithm DAG ledger model of the present embodiment has the following steps:

[0072] IntraConsensus. A block holds B transactions, there are N nodes in a shard, r is the epoch count, the details of intra-shard transaction consensus, the following steps are executed in a loop of r increment:

[0073] 1. Each node in the same shard selects B / N intra-shard transactions from the transaction pool, these transactions are denoted as proposed[i], where i is the node number.

[0074] 2. x[i] = Enc(IPK, proposed[i]), the transaction content is encrypted using a threshold encryption algorithm Enc to generate ciphertext x[i].

[0075] 3. The ciphertext x[i] is transmitted as input to the current node into ACS, and the output result of ACS is waited for, and the result output by ACS is a key share set {V} of all nodes.

[0076] 4. e[j] = Decshare(ISK[i], V[j]) traverses {V}, and performs threshold decryption operation on each key share V[j] to generate a decryption share, j is the key share number.

[0077] 5. Broadcast the decryption share message Dec(r, i, j, e[j]) to other nodes in the shard.

[0078] 6. Listen to the Dec message of other nodes, collect t, and use the public key IPK to recover the transaction set {Y}.

[0079] CrossConsensus. A block holds B transactions, there are N nodes in a shard, S is the number of shards, r is the epoch count, the details of cross-shard transaction consensus, the following steps are executed in a loop of r increment:

[0080] 1. Each node in the same shard selects B / (N*S) cross-shard transactions from the transaction pool, these transactions are denoted as proposed[i][j], i is the shard number, j is the node number in the shard.

[0081] 2. x[i][j] = Enc(PK, proposed[i][j]), the node uses a threshold encryption algorithm to encrypt the transaction content to generate ciphertext x[i][j].

[0082] 3. The ciphertext x[i][j] is transmitted as input to the current node into the ACS protocol process of the node, and the output result of the ACS process is waited for, and the result output by ACS is a key share set {V} of all nodes.

[0083] 4. e[k][l] = Decshare(SK[i][j], V[k][l]), traverse the secret share set {V}, perform threshold decryption operation on each key share to generate a decryption share, k is the shard number to which the key share belongs, and l is the key number in the shard.

[0084] 5. Broadcast the decryption share message Dec(r, i, j, k, l, e[k][l]) to other nodes in the shard.

[0085] 6. Listen to the Dec messages of other nodes, collect t*s, and use the public key PK to recover the transaction set {Y}.

[0086] The data storage layer of the blockchain system using the HoneyBadgerBFT consensus algorithm DAG ledger model of the embodiment is as follows:

[0087] Save(txs). txs is a transaction list, and the Save step is as follows:

[0088] 1. Verify the correctness of the transaction, remove duplicate transactions and invalid transactions.

[0089] 2. Execute the transaction content, modify the ledger data and state.

[0090] 3. Write the state after transaction execution into a block and link to the chain.

[0091] 4. Save the block to the disk and delete the executed transactions in the transaction pool.

[0092] Most of the current blockchain sharding systems are based on Pow or PBFT consensus. The Pow consensus is based on probability and cannot provide deterministic security. It needs to be confirmed by several blocks to ensure security with a high probability. In addition, in order to ensure the security of a single shard, nodes need to be randomly allocated when sharding to ensure that malicious nodes do not occupy the majority in the shard. In order to prevent malicious nodes from colluding and committing crimes at runtime, it is necessary to regularly shuffle and reallocate shards to the nodes, which greatly limits the running efficiency of the sharding system.

[0093] The sharding system using PBFT as the consensus protocol can provide deterministic security and does not need to wait for several blocks to ensure security. However, the PBFT protocol is based on timing assumptions and has high requirements for network environment. At the same time, the PBFT protocol has a performance bottleneck. When the number of network nodes increases, the network bandwidth of the master node becomes the bottleneck of the entire system, which limits the size of the system using PBFT as the consensus protocol.

[0094] The application uses the idea of fragmentation to divide the blockchain into several fragments, improves the expansibility of the whole system, supports a certain degree of transaction parallelism, and improves the system performance. The HoneyBadgerBFT protocol is used as a consensus means, which does not depend on the timing assumption and can be used in a more realistic and complex asynchronous network environment. In addition, all participating nodes participate in the entire consensus process, and there is no concept of master node, which overcomes the problem of master node bandwidth bottleneck.

[0095] The various embodiments are described in the specification in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be mutually referred to.

[0096] The principles and implementation modes of the application are described by applying specific examples in this paper. The above description of the embodiments is only used to help understand the method and core idea of the application. Meanwhile, for the general technical personnel in the field, the specific implementation mode and application range will be changed according to the idea of the application. In summary, the content of the specification should not be understood as a limitation of the application.

Claims

1. An asynchronous blockchain sharding system, characterized in that, The application layer, the consensus layer, and the data storage layer are included. The application layer is configured to construct a transaction model according to transaction information submitted by a user, store user transactions, and input the user transactions to the consensus layer for consensus at regular time intervals. The consensus layer is configured to determine an intra-shard transaction consensus protocol and a cross-shard transaction consensus protocol based on a HoneyBadgerBFT protocol, and perform consensus on transactions. The data storage layer is configured to store user transactions in a directed acyclic graph ledger. The process of the intra-shard transaction consensus is as follows: In the starting stage, private keys are assigned to nodes in a shard, and public keys are established between the nodes. The nodes encrypt the locally saved intra-shard transactions using a threshold encryption algorithm to generate ciphertext. The nodes broadcast the ciphertext and establish a binary transaction table. The binary transaction table is in the form of a key-value pair, the key name is unique, and is used to identify the node; the value is 0 or 1, and is used to indicate whether to accept the transaction proposal of the node. The nodes perform consensus according to the received ciphertext proposal and the binary transaction table. According to the consensus binary transaction table, the received transaction proposals are combined, threshold decryption is used to restore the original transaction data, the transaction is verified and de-duplicated, the transaction is executed, the data is chained, and the intra-shard transaction is removed from the transaction pool. The process of the cross-shard transaction consensus is as follows: In the starting stage, private keys are assigned to nodes in a shard, and public keys are established between the nodes. The nodes from different shards select cross-shard transactions as proposals from their respective transaction pools, encrypt the transactions using threshold encryption to generate ciphertext. The nodes broadcast the ciphertext and establish a binary transaction table. The nodes perform consensus according to the received ciphertext proposal and the binary transaction table. According to the consensus binary transaction table, the received transaction proposals are combined, threshold decryption is used to restore the original transaction data, the transaction is verified and de-duplicated, the transaction is executed, the data is chained, and the cross-shard transaction is removed from the transaction pool. The application layer includes a user interface, a transaction model, and a transaction pool.

2. The asynchronous blockchain sharding system of claim 1, wherein, The user interface is configured to interact with the asynchronous blockchain shard system. The transaction model is a data structure for processing transactions. The transaction pool is configured to store user transactions and input the user transactions to the consensus layer for consensus at regular time intervals. The user interface is a Web interface.

3. The asynchronous blockchain sharding system of claim 2, wherein, The data storage layer includes a ledger structure and a block structure.

4. The asynchronous blockchain sharding system of claim 1, wherein, In the ledger structure, intra-shard transactions are directly saved in the shard; cross-shard transactions are saved in the shards involved in the corresponding user transactions. The block structure includes blocks for saving cross-shard transactions and blocks for saving intra-shard transactions. ​

Images