A storage-oriented scalable alliance chain slicing method

Abstract

The application provides a storage scalable alliance chain slicing method, first classifies and identifies the Merkle tree leaf nodes when blocks are generated, then slices the generated tree after classification and identification, and finally uses error correction code to encrypt the storage structure. The method improves the storage scalability, reduces the impact of slicing on throughput, improves the storage efficiency and throughput, and reduces the shortage of storage hardware resources in the slicing process. At the same time, after fine-grained slicing, the separate address is saved, independent verification can be realized, and the verification efficiency is improved. Furthermore, the application maintains data based on the error correction code mark in the Merkle tree slicing, judges whether the data is hijacked through the decoding matrix, reduces the redundancy of copy replication for security, and improves the security of intra-block slicing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer blockchain query, in particular to a storage-extensible consortium chain slicing method. BACKGROUND

[0002] With the actual application scene of international data becoming more and more frequent, the term blockchain is gradually applied to enterprise and individual users. The characteristics of decentralization, modification resistance, data transparency and asymmetric encryption of the blockchain make it gradually applied by large enterprises in data management and other aspects. The blockchain is essentially a decentralized database, which is a new application mode of hybrid computer technologies such as various distributed encryption methods.

[0003] With more and more information uploaded to the blockchain, in recent years, especially on the Ethereum and Hyperledger consortium chain platforms, there is also a demand for storage expansion. However, the storage expansion technology in the field of blockchain is still in its infancy, and the traditional database sharding system transplanted to the blockchain system will bring security problems or cannot continue to meet the decentralization, which is also called the "impossible triangle" of the blockchain. Some excellent storage expansion algorithms have begun to be applied in public chains, and they have good resistance to harsh transaction environments and high security through complete system architecture. However, with the accumulation of data, the demand for storage expansion of the consortium chain also gradually increases. Unlike public chains, consortium chains do not need to sacrifice too much computing power to achieve storage expansion and security maintenance, so a more lightweight method design is needed compared to the sharding method on the public chain. SUMMARY

[0004] In view of the problems existing in the prior art, the present application provides a storage-extensible consortium chain slicing method, comprising:

[0005] Step 1: classifying and identifying the Merkle tree leaf nodes when generating a block; the specific expression is:

[0006] Step 1.1: extracting the digest of the user-written data; including:

[0007] Step 1.1.1: writing data to the local blockchain, filtering the key values of the hash block being generated and entered, the data is Sdata={data1,data2,…,datai,…,datam}, wherein m represents the total size of the data;

[0008] Step 1.1.2: for each data block, calculate its digest value dig=H(datai), wherein H() is a hash function, and sort all the digest values in character order to obtain a string S0;

[0009] Step 1.1.3: Divide the string S0 into n substrings of equal length, each substring is denoted as Si, for each substring Si, find the first element digj in the digest value that is greater than or equal to Si, and add datai to the dataset Sdig = {dig1, dig2, …, digj, …, dign} with digj as the key;

[0010] Step 1.1.4: Repeat step 1.1.2-step 1.1.3 until all data blocks are classified;

[0011] Step 1.2: Construct a Merkle tree according to the extracted digest; including:

[0012] Step 1.2.1: Perform prime sequence modulo operation on the extracted data digest Sdig = {dig1, dig2, …, dign}, and construct a tree from bottom to top according to the digest values dig with the same remainder, determine the branch from leaf node to parent node according to the remainder, and generate an index tree;

[0013] Step 1.2.2: Repeat step 1.2.1 until the entire Sdig = {dig1, dig2, …, dign} is constructed into a Merkle tree with classification identification, denoted as MT = {mt1, mt2, …, mtf}, where f represents the number of trees constructed according to the data;

[0014] Step 2: Slice the generated tree with classification identification, specifically expressed as:

[0015] Step 2.1: The generated block is immutable, for the data block being generated, along with the generation of the Merkle tree MTree = {mt1, mt2, …, mtf}, judge the number of layers of one of the Merkle trees, if it exceeds the threshold, then slice the left subtree separately at the current layer;

[0016] Step 2.2: In the MTree = {mt1, mt2, …, mtf} being generated, the left subtree is pruned and sliced, and the verification information of the right subtree and the root node is saved together with the left subtree, and the right subtree also saves the left subtree and the root node verification information, as shown in Figure 3 respectively save the left and right parts;

[0017] Step 2.3: Save the left and right subtrees as data blocks after slicing, divide the saved data into blocks C = {C0, …, Cg}, where g represents the number of data blocks, as shown in Figure 4 copy and save C = {C0, …, Cg} to different physical addresses;

[0018] Step 3: encrypt the storage structure using error correction code; the specific expression is:

[0019] Step 3.1: RS encoding is performed on the saved data block; the specific expression is: RS encoding is performed on the saved data block C={C0,...,Cg}, and each block is encoded into two check blocks v=(v1,v2,...,vs), u=(u1,u2,...,us) using the RS encoding check matrix and the generating matrix, and saved to the physical address where each shard is located;

[0020] Step 3.2: restore the generated code, send the check blocks v=(v1,v2,...,vs), u=(u1,u2,...,us) to the encoder at the sending end, and generate C={C0,...,Cg} by restoring the power of 2;

[0021] Step 3.3: for the saved data C={C0,...,Cg}, the hash tree verification is performed from the saved verification information Sdig={dig1,dig2,...,dign}; the specific expression is:

[0022] Step 3.3.1: first calculate the hash value hi=H(C) of each leaf node C={C0,...,Cg}, then concatenate all hi in order to obtain a string H0;

[0023] Step 3.3.2: for each non-leaf node, concatenate the labels of its left and right child nodes to obtain a string H1; for each non-leaf node, calculate its label hi=H(H1);

[0024] Step 3.3.3: repeat step 3.3.1 and step 3.3.2 until the root node hr is obtained, and finally compare hr with the first element dig1 in Sdig; if they are equal, the verification is successful; otherwise, the verification fails.

[0025] The beneficial effects of the present application are:

[0026] The present application is a Merkle tree block internal fragmentation method based on the characteristics of the alliance chain, which improves the storage scalability, reduces the impact of fragmentation on throughput, and improves the storage efficiency and throughput, and reduces the storage hardware resource shortage in the fragmentation process. At the same time, after fine-grained fragmentation, separate address saving can be realized, which can realize independent verification and improve the verification efficiency. Furthermore, the present application maintains data based on the error correction code label in the Merkle tree fragmentation, judges whether the data is hijacked by decoding the matrix, reduces the redundancy of copy replication for security, and improves the security of block internal fragmentation. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1 A schematic diagram of a platform-oriented parallel running structure of the present application;

[0028] Figure 2 A schematic diagram of a storage-oriented expandable alliance chain sharding index tree of the present application;

[0029] Figure 3 A schematic diagram of a storage-oriented expandable alliance chain sharding method model of the present application;

[0030] Figure 4 A schematic diagram of a security sharding structure based on error correction code of the present application;

[0031] Figure 5 A flowchart of a storage-oriented expandable alliance chain sharding method of the present application. DETAILED DESCRIPTION

[0032] The application will be further described below in combination with the drawings and specific implementation examples.

[0033] The sharding system can theoretically improve the storage performance of the entire system, but the communication cost will be increased due to sharding, resulting in low verification efficiency. During the sharding process, if multiple transactions are concentrated in a node at the same time, and the node performs sharding operation, congestion may occur, so it is necessary to optimize the loss caused by sharding. Since the Mp-tree architecture is a fine-grained sharding process included in block generation, the sharding process can be parallelized in the block generation process, thereby further reducing the loss caused by the sharding system. Moreover, independent verification can be achieved by saving the verification information of the sharding in the same physical address, and the verification efficiency is improved. In order to ensure the independent verification result, error correction code is used to guarantee the security of the restored data.

[0034] The implementation of the present application utilizes the Fabric1.0 platform to divide the node functions, so the multi-channel function can be used to integrate the process of sharding generated by the Merkle tree into the node, and the sharding is parallelized in the block generation. The specific principle diagram is shown in Figure 1 .

[0035] The present application provides a storage-oriented expandable alliance chain sharding method, as shown in Figure 5 , which comprises:

[0036] Step 1: classifying and identifying the Merkle tree leaf nodes during block generation; the specific expression is:

[0037] Step 1.1: extracting the digest of the user-written data; comprising:

[0038] Step 1.1.1: User writes data to local blockchain, and the hash block being generated is screened by key value, and the data is Sdata = {data1, data2, …, datai, …, datam}, where m represents the total size of the data;

[0039] Step 1.1.2: For each data block, calculate its digest value dig = H(datai), where H() is a hash function, and sort all digest values in character order to obtain a string S0;

[0040] Step 1.1.3: Divide the string S0 into n substrings of equal length, and for each substring Si, find the first element digj in the digest value that is greater than or equal to Si, and add datai to the dataset Sdig = {dig1, dig2, …, digj, …, dign} with digj as the key;

[0041] Step 1.1.4: Repeat steps 1.1.2-1.1.3 until all data blocks are classified;

[0042] Step 1.2: Construct a Merkle tree according to the extracted digest; including:

[0043] Step 1.2.1: The first layer is the root node, and the root node has two nodes, and each node is followed by the same. The extracted data digest Sdig = {dig1, dig2, …, dign} is taken modulo a prime sequence, and the digest values dig with the same remainder are saved to the same subtree from bottom to top, and the branching path from leaf node to parent node is determined according to the remainder, until the target node is found, and an index tree is generated; for example, according to the character segment, a B+ tree is generated as shown in Figure 2 .

[0044] Step 1.2.2: Repeat step 1.2.1 until the entire Sdig = {dig1, dig2, …, dign} is constructed into a Merkle tree with classification identifier, denoted as MT = {mt1, mt2, …, mtf}, where f represents the number of trees constructed according to the data;

[0045] Step 2: Sharding the generated tree with classification identifier, specifically:

[0046] Step 2.1: The generated block is immutable, and for the data block being generated, along with the generation of the Merkle tree MTree = {mt1, mt2, …, mtf}, one of the Merkle trees is judged by the number of layers of the tree, and if it exceeds the threshold, the left subtree is separately sharded at the current layer;

[0047] Step 2.2: In the MTree being generated = {mt1, mt2,..., mtf}, the left subtree is pruned and saved, and the right subtree and the verification information of the root node are saved together to the left subtree, and the right subtree also saves the left subtree and the root node verification information, which is convenient for subsequent separate verification. The sliced Merkle tree can be verified within the slice without re-composing the complete tree. As shown in Figure 3 , the left and right parts are saved respectively, and the left subtree contains the root node and the Hashright information of the right subtree of the root node, which are saved uniformly. The right subtree saves the root node and the left subtree information, so that the left and right subtrees after slicing can be independently verified in the verification process.

[0048] Step 2.3: After slicing the left and right subtrees, save them as data blocks, and divide them into blocks C = {C0,...,Cg} according to the saved data, where g represents the number of data blocks, as shown in Figure 4 , copy and save C = {C0,...,Cg} to different physical addresses;

[0049] As shown in Figure 3 , in the process of dividing the blocks into M = {mt1, mt2,..., mtf} at each node, if slicing is performed after the construction of the block Merkle tree, the slicing cost will be additionally increased, reducing the system performance. Therefore, in the Mp tree construction process, whenever the parent node is constructed upwards, the information of the corresponding transaction data node is directly sliced and stored in the storage node, which can realize parallel slicing and reduce the cost after slicing. In the process of generating the Merkle tree, the root node and the verification information of another node are additionally saved in the other party, as shown in the example, when slicing the left and right subtrees, Hash12 additionally saves the information of Hash1234 and Hash34, and then the Merkle tree is sliced, each slice corresponds to a subtree. In order to facilitate data restoration, the root node is always saved in the last slice subtree. Based on the slicing of the root node, it is divided into two parts, the first half is the sliced tree with Hash12 as the new root node, and the second half is the sliced storage with Hash1234 as the root node.

[0050] Step 3: Use error correction code to encrypt the storage structure; the specific expression is:

[0051] Step 3.1: RS encoding (Reed-solomon codes) is performed on the saved data blocks; the specific expression is: RS encoding is performed on the saved data blocks C = {C0,...,Cg}, and each block is encoded into two check blocks v = (v1, v2,...,vs), u = (u1, u2,...,us) using the RS encoding check matrix and generator matrix, and an additional check block is generated for each block for verification by RS encodingFigure 4 are shown and saved to the physical address where each shard is located;

[0052] Step 3.2: The generated code is restored, and at the sending end, the check block v = (v1, v2,..., vs), u = (u1, u2,..., us) is sent to the encoder, and the C = {C0,..., Cg} is generated by restoring the power of 2, which will not be affected by the new data block;

[0053] Step 3.3: For the saved data C = {C0,..., Cg}, the hash tree verification is performed from the saved verification information Sdig = {dig1, dig2,..., dign}; The specific expression is:

[0054] Step 3.3.1: First, calculate the hash value hi = H(C) of each leaf node C = {C0,..., Cg}, and then connect all hi in order to obtain a string H0;

[0055] Step 3.3.2: For each non-leaf node, connect the labels of its left and right child nodes to obtain a string H1; For each non-leaf node, calculate its label hi = H(H1);

[0056] Step 3.3.3: Repeat step 3.3.1 and step 3.3.2 until the root node hr is obtained, and finally compare hr with the first element dig1 in Sdig. If they are equal, the verification is successful; otherwise, the verification fails.

Claims

1. A storage-scalable consortium blockchain sharding method, characterized in that, include: Step 1: Classify and label the Merkle tree leaf nodes during block generation; Step 1.1: Extract a summary from the user-written data; Step 1.1.1: The user writes data to the local blockchain and filters the key values ​​of the hash blocks being generated and entered. The data is Sdata={data1,data2,…,datai,…,datam}, where m represents the total size of the data. Step 1.1.2: For each data block, calculate its digest value dig = H(datai), where H() is a hash function. Sort all digest values ​​in character order to obtain a string S0. Step 1.1.3: Divide the string S0 into n substrings of equal length, each substring is represented as Si. For each substring Si, find the first element digj in the digest value that is greater than or equal to Si, and add datai to the verification information dataset Sdig={dig1, dig2, …, digj…, dign} with digj as the key; Step 1.1.4: Repeat steps 1.1.2-1.1.3 until all data blocks have been classified; Step 1.2: Construct a Merkle tree based on the extracted summary; Step 2: Divide the generated tree after classification and labeling into segments; Step 3: Encrypt the storage structure using error-correcting codes; Step 3.1: Perform RS encoding on the saved data blocks; Step 3.2: Restore the generated code. At the sending end, send the check block v=(v1, v2, ..., vs) and u=(u1, u2, ..., us) to the encoder. Generate C={C0, ..., Cg} by restoring the power of 2. Step 3.3: For the saved data C={C0, ..., Cg}, perform hash tree verification from it using the saved verification information dataset Sdig={dig1, dig2, …, dign}.

2. The storage-scalable consortium blockchain sharding method according to claim 1, characterized in that, Step 1.2 includes: Step 1.2.1: Perform prime number sequence modulo operation on the extracted verification information dataset Sdig={dig1, dig2, …, dign}, construct a tree from bottom to top for the summary values ​​dig with the same remainder, determine the branches from the leaf nodes to the parent nodes based on the remainders, and generate an index tree; Step 1.2.2: Repeat step 1.2.1 until the entire verification information dataset Sdig={dig1, dig2, …,dign} is constructed into a Merkle tree with classification labels, denoted as MT={mt1, mt2, …, mtf}, where f represents the number of trees constructed based on the data.

3. The storage-scalable consortium blockchain sharding method according to claim 1, characterized in that, Step 2 includes: Step 2.1: The generated blocks are immutable. For the data blocks being generated, along with the generation of the Merkle tree MTree={mt1, mt2, …, mtf}, one of the Merkle trees is judged according to the level of the tree. If it exceeds the threshold, the left subtree is split separately at the current level. Step 2.2: In the MTree={mt1, mt2, …, mtf} being generated, the left subtree is pruned and fragmented for storage, and the verification information dataset Sdig of the right subtree and the root node is saved to the left subtree. The right subtree also saves the verification information dataset Sdig of the left subtree and the root node, saving the left and right parts respectively. Step 2.3: After the left and right subtrees are fragmented, they are saved as data blocks. The data is divided into blocks C={C0,..., Cg}, where g represents the number of data blocks. The C={C0,..., Cg} blocks are encoded, copied, and saved to different physical addresses.

4. The storage-scalable consortium blockchain sharding method according to claim 1, characterized in that, Step 3.1 is specifically described as follows: RS encoding is performed on the already saved data block C={C0, ... , Cg}. The RS encoding check matrix and generator matrix are used to encode each block into two check blocks v=(v1, v2, ..., vs) and u=(u1, u2, ..., us), and they are saved to the physical address where each fragment is located.

5. The storage-scalable consortium blockchain sharding method according to claim 1, characterized in that, Step 3.3 is specifically described as follows: Step 3.3.1: First, calculate the hash value hi=H(C) of each leaf node C={C0, ..., Cg}, and then concatenate all the hi values ​​in order to obtain a string H0; Step 3.3.2: For each non-leaf node, concatenate the labels of its left and right child nodes to obtain a string H1; for each non-leaf node, calculate its label hi = H(H1); Step 3.3.3: Repeat steps 3.3.1 and 3.3.2 until the root node hr is obtained. Finally, compare hr with the first element dig1 in the verification information dataset Sdig. If they are equal, the verification is successful; otherwise, the verification fails.

Images