A centralized block slicing verification system for enhancing the decentralization degree of a consortium chain

Abstract

The application discloses a centralized block output and slice verification system for enhancing the decentralization degree of an alliance chain, a transaction sending module packs a plurality of selected transactions in a transaction pool into a transaction block; a transaction running module receives the transaction block, runs all transactions in the transaction block and generates a state read-write set; a Ledger tree module divides all read-write states generated in the transaction running process, performs slicing and generates a double Merkle tree according to the state read-write set; a block verification module performs consensus and slicing on the transaction block generating the double Merkle tree, and then performs operation according to the read-write state set of all transactions in the slice, to obtain a Ledgerroot; comparison between the Ledgerroot and a Merkle root of the Merkle tree itself can verify the correctness of all transactions. The centralized block output and slice verification system has the advantages of reducing communication consumption, reducing the difficulty and cost of processing cross-slice transactions and the like.

Description

TECHNICAL FIELD

[0001] The present application relates to a consortium chain sharding verification technology, in particular to a centralized block output sharding verification system for enhancing the decentralization degree of a consortium chain. BACKGROUND

[0002] A block chain is a block chain storage, tamper-proof, secure and trusted decentralized distributed ledger, which combines distributed storage, peer-to-peer transmission, consensus mechanism, cryptography and other technologies, and records transactions and information through a growing chain of blocks (Blocks) to ensure data security and transparency. After years of development, the block chain technology has gradually formed two paths: one is a non-permission chain (public chain) with digital assets as a typical application, and the other is a permission chain (consortium chain) driven by digital collaboration.

[0003] The openness of the permission chain is between the public chain and the private chain, and the openness of the control system can be customized. In the permission chain, the number of nodes is relatively small, and the trust is limited to a few nodes. Even if the ordinary user has the right to obtain block data, the user is difficult to have sufficient machine configuration and network bandwidth to verify and process the block. Therefore, the permission chain faces a serious centralization problem.

[0004] Sharding is widely used in distributed databases and cloud facilities, and is one of the most practical solutions to achieve scalable systems so far, and the processing, storage and computing processes can be performed in parallel. The sharding technology can overcome the scalability problem of the block chain technology, and as a chain expansion way that can achieve the high performance goal of the block chain without sacrificing the centralization degree, the sharding technology has gradually become one of the mainstream of the block chain expansion technology.

[0005] In the prior art, some permission chain sharding schemes allow more nodes to join. The node consumption is reduced by sharding, although the decentralization degree is increased, and the node consumption is reduced by sharding. However, this permission chain sharding scheme still has problems such as high communication cost and difficulty. SUMMARY

[0006] The present application is to avoid the shortcomings in the prior art, and to provide a centralized block output sharding verification system for enhancing the decentralization degree of a consortium chain with lower cost and higher efficiency, so as to reduce the sharding communication consumption of the permission chain sharding scheme.

[0007] The present application adopts the following technical solutions to solve the technical problems.

[0008] The centralized block output sharding verification system for enhancing the decentralization degree of a consortium chain comprises a transaction sending module, a transaction running module, a Ledger tree module and a block verification module.

[0009] The transaction sending module is configured to receive transactions sent by multiple clients and place all the received transactions in a transaction pool, and then pack multiple selected transactions in the transaction pool into a transaction block.

[0010] The transaction running module is configured to receive the transaction block and run all the transactions in the transaction block to generate a state read-write set.

[0011] The Ledger tree module is configured to divide all the read-write states generated by the transactions in the transaction running process, and perform sharding and generate a double Merkle tree according to the state read-write set.

[0012] The block verification module is configured to perform consensus and sharding on the transaction block for which the double Merkle tree is generated, and then perform operation according to the read-write state set of all the transactions in the sharded block to obtain a Ledgerroot, and compare the Ledgerroot with a Merkle root of the Merkle tree itself to verify the correctness of all the transactions.

[0013] The centralized block sharding and verification system for enhancing the decentralization degree of the alliance chain also has the following characteristics:

[0014] In specific implementation, the transaction sending module includes consensus nodes and participating nodes.

[0015] In specific implementation, the transaction block includes a number Number, a hash value of a parent block, a Ledger root directory LedgerRoot, a time stamp TimesTamp and a list Tx List.

[0016] In specific implementation, when running all the transactions in the transaction block, the read-write states of all the transactions are listed one by one.

[0017] In specific implementation, the Ledger tree module includes a read-write state division module and a Ledger tree generation module.

[0018] In specific implementation, the block verification module includes a sharding module and a verification module.

[0019] In specific implementation, in the sharding module, the states of the sharding are divided into local states LOCAL and cross-sharding states CROSS.

[0020] In specific implementation, in the sharding module, the transactions between different accounts are divided into corresponding shards according to the addresses of the senders.

[0021] In the implementation, in the verification module, a LedgerRoot is obtained through the Merkle tree operation, and the correctness of all transactions can be verified by comparing the LedgerRoot with the Merkle root of the Merkle tree.

[0022] Compared with the prior art, the application has the beneficial effects of:

[0023] The application discloses a centralized block slicing verification system for enhancing the decentralization degree of a consortium chain, wherein a transaction sending module packs a plurality of transactions selected from a transaction pool into a transaction block; a transaction running module is used for receiving the transaction block and generating a state read-write set, and running all transactions in the transaction block; a Ledger tree module is used for dividing all read-write states generated in the transaction running process, and performing slicing and generating a double Merkle tree according to the state read-write set; and a block verification module is used for performing consensus and slicing on the transaction block of the double Merkle tree, and performing operation according to the read-write state set of all transactions in the slicing, to obtain a LedgerRoot, and the correctness of all transactions can be verified by comparing the LedgerRoot with the Merkle root of the Merkle tree.

[0024] The centralized block slicing verification system for enhancing the decentralization degree of the consortium chain has the advantages of reducing communication consumption, reducing the difficulty and cost of processing cross-slice transactions, and the like. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 It is a verification process of the centralized block slicing verification system for enhancing the decentralization degree of the consortium chain.

[0026] Figure 2 It is a transaction sending and block packing process of the centralized block slicing verification system for enhancing the decentralization degree of the consortium chain.

[0027] Figure 3 It is a state read-write set generation process of the centralized block slicing verification system for enhancing the decentralization degree of the consortium chain.

[0028] Figure 4 It is a double Merkle tree of the centralized block slicing verification system for enhancing the decentralization degree of the consortium chain.

[0029] Figure 5 It is a Merkle tree verification process of the centralized block slicing verification system for enhancing the decentralization degree of the consortium chain.

[0030] Figure 6A shard diagram of a block verification module of a centralized block production and sharding verification system for enhancing the decentralization degree of a consortium chain.

[0031] Figure 7 A diagram of sharding according to account addresses of a centralized block production and sharding verification system for enhancing the decentralization degree of a consortium chain.

[0032] Figure 8 A verification process diagram in a block verification module of a centralized block production and sharding verification system for enhancing the decentralization degree of a consortium chain.

[0033] The application is further described below by means of specific embodiments and in conjunction with the accompanying drawings. DETAILED DESCRIPTION

[0034] Reference Figures 1-8 The centralized block production and sharding verification system for enhancing the decentralization degree of a consortium chain comprises a transaction sending module, a transaction running module, a Ledger tree module, and a block verification module.

[0035] The transaction sending module is configured to receive transactions sent by multiple clients and place all the received transactions in a transaction pool, and then pack multiple transactions selected from the transaction pool into a transaction block.

[0036] The transaction running module is configured to receive the transaction block and run all the transactions in the transaction block to generate a state read-write set.

[0037] The Ledger tree module is configured to divide all the read-write states generated in the transaction running process, and perform sharding and generate a double Merkle tree according to the state read-write set.

[0038] The block verification module performs consensus and sharding on the transaction block generating the double Merkle tree, and then performs operation according to the read-write state set of all the transactions in the shard to obtain a Ledgerroot, which is compared with the Merkle root of the Merkle tree itself to verify the correctness of all the transactions.

[0039] As Figure 1 The flowchart is a verification process of the centralized block production and sharding verification system for enhancing the decentralization degree of a consortium chain. In the application, the double state Merkle tree (DSM Tree) is used to facilitate the consensus nodes to uniformly perform sharding on the states, which is conducive to reducing the sharding communication consumption, and finally the verification nodes can use the DSM Tree to verify the correctness of the transactions in a shard. The application scenarios of the application include but are not limited to transaction payment, but the following is an example of transaction payment to describe the verification process of the application.

[0040] In specific implementation, the transaction sending module includes consensus nodes and participating nodes.

[0041] As Figure 1 and Figure 2 The transaction sending module includes multiple nodes. The nodes are divided into consensus nodes and participating nodes. The consensus nodes are used for block generation. After receiving transactions sent by multiple clients, the consensus nodes include all the transactions in a transaction pool, and then select multiple transactions from the transaction pool to package into a transaction block.

[0042] The participating nodes are used for verifying the information of the slices in the block. The enhanced centralized block generation and slice verification system for decentralizing the alliance chain can verify the correctness of the transactions in the block through the Ledger tree module and the block verification module.

[0043] In specific implementation, the transaction block includes a number Number, a hash value of a parent block, a Ledger root LedgerRoot, a timestamp TimesTamp and a list TxList.

[0044] The transaction block includes a number Number (i.e., block height), a hash value of a parent block, a Ledger root LedgerRoot (i.e., a hash value of the block itself), a timestamp TimesTamp (i.e., the time when the current block is generated) and a list TxList (i.e., a transaction information list). The LedgerRoot is a key component for storing the Ledger metadata.

[0045] In specific implementation, when running all transactions in the transaction block, the read-write states of all transactions are listed one by one.

[0046] As Figure 1 and Figure 3 The transaction block is forwarded to other consensus nodes, all transactions in the transaction block are run, and the read-write states of all transactions are listed one by one, the read sender balance, the write sender balance, the read receiver balance and the write receiver balance.

[0047] In specific implementation, the Ledger tree module includes a read-write state division module and a Ledger tree generation module.

[0048] The read-write state division module divides all read-write states generated by the transaction according to the states. The read-write state is a hash value, that is, a 32-bit byte array.

[0049] The Ledger tree generation module can generate a double Merkle tree (Merkle tree) according to the state read-write set, obtain a Merkle tree root of itself, and place the Merkle tree root into the ledgerroot, as shown in Figure 4

[0050] As shown in Figure 5 , the Merkle tree is a binary tree, the leaf node of which is the result of hashing the original data according to a specified hash function, and the non-leaf node is calculated from the hash values of its child nodes. The Merkle tree has a collision resistance, and this structure allows the integrity of the data to be verified without reading all the data. Only the Merkle tree root, the Merkle path and the leaf node to be verified are needed to verify the correctness of the leaf node data.

[0051] For example, in Figure 5 , to verify the correctness of node c, only the values of Hash_c, Hash_d, Hash_a_b, Hash_e_f_g_h need to be downloaded, and then the SHA-256 hash algorithm is used for hash operation to obtain a Merkle root hash value (MerkleRoot), and then the calculated Merkle root hash value (MerkleRoot) is compared with the correct Merkle tree root initial value obtained. The Merkle root tree root initial value is generated by layer-by-layer hash calculation of the original data. When comparing, if the Merkle root hash value and the Merkle root tree root initial value are the same, it means that node c is correct. If the Merkle root hash value and the Merkle root tree root initial value are not the same, it means that the node c is incorrect.

[0052] Since the Merkle tree has a collision resistance, if the hash value of node c changes slightly, the Merkle root hash value obtained by hash operation will be very different, so only the calculated Merkle root hash value (MerkleRoot) and the correct Merkle tree root obtained can be compared to verify the correctness of node c.

[0053] The Merkle root hash value calculation process mentioned above in the present application is as follows:

[0054] 1. Original data block: c

[0055] 2. Leaf node:

[0056] Hash_c = Hash(c)

[0057] 3. Internal node:

[0058] ​Hash_c_d = Hash(Hash_c||Hash_d)

[0059] Hash_a_b_c_d = Hash(Hash_c_d||Hash_a_b)

[0060] 4. Root node:

[0061] Hash_a_b_c_d_e_f_g_h (MerkleRoot) = Hash(Hash_a_b_c_d||Hash_e_f_g_h)

[0062] In specific implementation, the block verification module comprises a sharding module and a verification module.

[0063] In specific implementation, in the sharding module, the state of sharding is divided into a local state LOCAL and a cross-sharding state CROSS.

[0064] As Figure 6 , in the block verification module, after the ledger tree is generated, consensus is performed on the transaction block; after the consensus is completed, approval is reached on the transaction block, and the generated block is sharded. The sharding content comprises the generated ledger root, the transactions contained in the corresponding shard, and the transaction read-write state set. For each shard, the local state LOCAL and the cross-sharding state CROSS of the shard can be divided.

[0065] As Figure 7 , in the transaction "2_xx sends 747 to 0_xx", there are four records of "read 2", "write 2", "read 0" and "write 0". Among them, "read 2" and "write 2" in shard 2 are records of the local state LOCAL, and "read 0" and "write 0" are records of the cross-sharding state CROSS, while "read 0" and "write 0" in shard 0 are records of the local state LOCAL.

[0066] In specific implementation, in the sharding module, the transactions between different accounts are divided into corresponding shards according to the address of the sender.

[0067] The number of block shards is generally a multiple of 2. Taking a multiple of 2 as an example, the address space of the account is divided according to the address. According to the first k bits of the address of the account and the state, 2 k shards can be divided, which are {0, 1, 2, … 2 k-1}. The number of shards is denoted by K, K = 2 k . Different shards only store the transactions of the accounts in the shard and the value of the state in the shard. All accounts and states are divided into corresponding shards.

[0068] Transactions between different accounts are divided into corresponding shards according to the address of the sender, as shown in Figure 7 The transaction "2_xx send 747 to 0_xx" is sent by shard 2 and is divided into shard 2. The transaction "1_xx send 54 to 3_xx" is sent by shard 1 and is divided into shard 1.

[0069] In specific implementation, in the verification module, a LedgerRoot can be obtained through Merkle tree operation, and the Ledgerroot is compared with the Merkle root of the Merkle tree itself, so that the correctness of all transactions can be verified.

[0070] The transaction block itself knows the ledgerRoot tree root, and the verification node only needs to know the Merkle tree root, the read-write state set of all transactions in each shard and the verification path, so that the correctness of the transaction can be verified, and all are known.

[0071] As shown in Figure 8 , the root value of the shard tree can be obtained according to the Local value of a certain shard and the verification path of the shard tree. The read-write state set of all transactions in each shard is known, and the Local value corresponding to the shard where the transaction recipient is located can be obtained. For example, the read-write state set of the transaction "1_xx send 54 to 3_xx" in shard 1 can obtain the Local value "R3_xx" and "W3_xx" of the transaction "1_xx send 54 to 3_xx" in shard 3. Then, all shared tree roots can be obtained, and a LedgerRoot can be obtained by performing Merkle tree operation, and the correctness of all transactions can be verified by comparing it with the Merkle root itself.

[0072] As shown in Figure 1 , the centralized block slicing and verification system for enhancing the decentralization degree of the alliance chain is one of the present application, which has the following technical characteristics.

[0073] 1. The DSM Tree is realized by centralized block slicing (that is, there is a packer with all states), which can reduce communication consumption and cost. The consensus node of centralized block slicing can select a machine with higher performance, and then cooperate with a dedicated line network to realize high performance.

[0074] 2. In the present application, transaction locking is not required, and no additional cross-shard transaction consumption (communication, etc.) is generated, thereby reducing the difficulty and cost of processing cross-shard transactions and enhancing the decentralization degree of the system.

[0075] 3. In the system of the present invention, ordinary consumer machines can be selected, and the verification nodes use sharding technology to reduce the cost of verifying blocks.

[0076] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above and that the invention can be embodied in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered in all respects as illustrative and non-restrictive, and the scope of the invention is defined by the appended claims, not the foregoing description, and all variations within the meaning and range of equivalents of the claims are intended to be included therein. Any reference sign in a claim should not be construed as limiting the claim to which it relates.

[0077] In addition, it should be understood that although this specification is described in terms of implementation methods, not every implementation method contains only one independent technical solution. This narrative method of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other implementation methods that can be understood by those skilled in the art.

Claims

1. A centralized block generation and sharding verification system that enhances the decentralization of the alliance chain, characterized by: Includes transaction sending module, transaction execution module, Ledger tree module and block verification module; The transaction sending module is used to receive transactions sent by multiple clients and place all received transactions into a transaction pool, and then select multiple transactions from the transaction pool and package them into a transaction block; The transaction execution module is used to receive the transaction block, execute all transactions in the transaction block and generate a state read-write set; the transaction sending module includes a consensus node and a participating node; the consensus node is used to generate blocks; the participating node is used to verify the information of the shards in the block; The Ledger tree module is used to divide all read and write states generated by transactions during the transaction process, and to perform sharding and generate a double Merkle tree based on the state read and write sets; The block verification module performs consensus and sharding on the transaction blocks that generate the double Merkle tree, and then calculates the read and write status sets of all transactions in the shards to obtain a Ledgerroot. By comparing the Ledgerroot with the Merkle root of the Merkle tree itself, the correctness of all transactions can be verified.

2. A centralized block generation and sharding verification system for enhancing the decentralization of a consortium chain according to claim 1, characterized in that: The transaction block includes a number, a hash value of the parent block, a Ledger root ‌LedgerRoot‌, a timestamp TimesTamp, and a list Tx List.

3. A centralized block generation and sharding verification system for enhancing the decentralization of a consortium chain according to claim 1, characterized in that: When running all transactions in the transaction block, the read and write status of all transactions are listed one by one.

4. A centralized block generation and sharding verification system for enhancing the decentralization of a consortium chain according to claim 1, characterized in that: The Ledger tree module includes a read-write state division module and a Ledger tree generation module.

5. The centralized block generation and sharding verification system for enhancing the decentralization of the alliance chain according to claim 1 is characterized in that: The block verification module includes a sharding module and a verification module.

6. A centralized block generation and sharding verification system for enhancing the decentralization of a consortium chain according to claim 5, characterized in that: In the sharding module, the sharding state is divided into a local state LOCAL and a cross-sharding state CROSS.

7. A centralized block generation and sharding verification system for enhancing the decentralization of a consortium chain according to claim 5, characterized in that: In the sharding module, transactions between different accounts are divided into corresponding shards according to the sender's address.

8. A centralized block generation and sharding verification system for enhancing the decentralization of a consortium chain according to claim 7, characterized in that: The number of the slices is an even number.

9. A centralized block generation and sharding verification system for enhancing the decentralization of a consortium chain according to claim 5, characterized in that: In the verification module, a LedgerRoot can be obtained through Merkle tree calculation. By comparing the LedgerRoot with the Merkle root of the Merkle tree itself, the correctness of all transactions can be verified.

Images