Distributed storage method of blockchain

Abstract

This application discloses a distributed storage method for blockchain, which includes: generating a set of coded fragments corresponding to a target block and a hash value corresponding to each coded fragment according to a preset erasure coding technique, wherein the number of each coded fragment is the same as the number of client nodes, and the set of coded fragments contains all block data of the target block and redundant coded fragments equal to the number of tolerable Byzantine nodes; generating a Merkle tree and a Merkle tree path using the hash values ​​corresponding to each coded fragment as leaf nodes; broadcasting each coded fragment and its corresponding Merkle tree path to the corresponding client nodes for verification and confirmation by each client node to determine whether consensus needs to be reached with the server master node; and storing the set of coded fragments corresponding to the target block on each consensus client node after consensus is reached. Therefore, this application optimizes the storage performance of blockchain while ensuring the correctness and integrity of the stored transaction data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, in particular to a distributed storage method of blockchain. BACKGROUND

[0002] Since the blockchain has the tamper-proof property, using the blockchain to store transaction data is convenient for supervision and verification, so in the prior art, transaction data is often stored on the blockchain. However, with the increasing amount of transaction data, the storage demand for the blockchain is increasing. How to improve the storage capacity of the blockchain to store the increasing transaction data has become the focus of the personnel in the field.

[0003] In summary, there is an urgent need for a distributed storage method of blockchain to improve the storage performance of the blockchain. SUMMARY

[0004] Therefore, the present application provides a distributed storage method of blockchain to improve the storage performance of the blockchain.

[0005] In order to achieve the above-mentioned purpose, the present scheme is as follows:

[0006] A distributed storage method of blockchain, the nodes on the blockchain include one server master node, at least one server backup node and at least two client nodes, the method is applied to the server master node, and includes:

[0007] According to a predetermined error correction code technology, a set of encoding segments corresponding to a target block on the blockchain and a hash value corresponding to each encoding segment in the set of encoding segments are generated, wherein the number of each encoding segment in the set of encoding segments corresponding to the target block is the same as the number of the client nodes, the set of encoding segments contains all block data of the target block, and the set of encoding segments contains redundant encoding segments with the same number of tolerable Byzantine nodes;

[0008] The hash values corresponding to each encoding segment are taken as leaf nodes to generate a Merkle tree storing the hash values corresponding to each encoding segment;

[0009] A Merkle tree path corresponding to each encoding segment is generated, and the Merkle tree path corresponding to the encoding segment records all leaf nodes required to be passed through from the leaf node corresponding to the encoding segment in the Merkle tree corresponding to the target block to the root node of the Merkle tree;

[0010] broadcasting each encoded segment and its corresponding Merkle tree path to the corresponding client node, so that the client nodes verify the encoded segment and its corresponding Merkle tree path, and determine whether consensus needs to be formed with the server master node; after the consensus is formed, the encoded segment set corresponding to the target block is stored in each consensus client node, wherein N is the number of client nodes on the blockchain, the number of consensus client nodes is a positive integer and is not less than 2N / 3, N is an integer and is not less than 2.

[0011] A distributed storage method of a blockchain, the nodes on the blockchain include a server master node, at least one server backup node, and at least two client nodes, the method is applied to a client node, and includes:

[0012] receiving an encoded segment and a Merkle tree path corresponding to the encoded segment sent by the server master node and matched with the node, wherein the encoded segment is obtained by encoding a target block on the blockchain by using a preset error correction code technology, and the Merkle tree path corresponding to the encoded segment records all leaf nodes required to be passed through from a leaf node corresponding to the encoded segment in a Merkle tree corresponding to the target block to a root node of the Merkle tree;

[0013] verifying whether the received encoded segment is correct according to the encoded segment and the Merkle tree path corresponding to the encoded segment;

[0014] if correct, storing the received encoded segment;

[0015] broadcasting a signature and a verification result to each client node except the node, so that each client node forms a consensus;

[0016] determining whether the number of received signatures and verification results broadcast by each client node except the node is not less than a threshold value, wherein N is the number of client nodes on the blockchain, the threshold value is 2N / 3, N is an integer and is not less than 2;

[0017] if the number of signatures and verification results is not less than the threshold value, broadcasting confirmation information to the server master node and the client nodes except the node, so that the server master node forms a consensus with the client nodes whose number is not less than 2N / 3 after confirming that the number of confirmation information is not less than the threshold value, to store each encoded segment of the target block in each consensus client node.

[0018] It can be seen from the above technical solutions that the nodes on the blockchain include a server master node, at least one server backup node, and at least two client nodes. The distributed storage method of the blockchain provided by the present application is mainly applied to the server master node. First, a set of encoding fragments corresponding to a target block on the blockchain and a hash value corresponding to each encoding fragment in the set of encoding fragments can be generated according to a preset error correction code technology. The number of encoding fragments in the set of encoding fragments corresponding to the target block is the same as the number of client nodes. The set of encoding fragments contains all block data of the target block, and the set of encoding fragments contains redundant encoding fragments with the same number of tolerable Byzantine nodes. Therefore, when all encoding fragments are stored on the blockchain, the storage of all block data of the block can be completed. The hash value corresponding to each encoding fragment is used as a leaf node to generate a Merkle tree that stores the hash value corresponding to each encoding fragment. A Merkle tree path corresponding to each encoding fragment can be generated. The Merkle tree path corresponding to the encoding fragment records all leaf nodes that need to be passed through from the leaf node corresponding to the encoding fragment in the Merkle tree corresponding to the target block to the root node of the Merkle tree, so that the client nodes can find the hash value matching the Merkle tree path on the Merkle tree based on the Merkle tree path, and verify the integrity and correctness of the received encoding fragment based on this. Each encoding fragment and its corresponding Merkle tree path are broadcast to the corresponding client nodes for verification between the client nodes based on the encoding fragment and its corresponding Merkle tree path, and it is confirmed whether consensus needs to be formed with the server master node. After the consensus is formed, the set of encoding fragments corresponding to the target block is stored in each consensus client node. N is the number of client nodes on the blockchain, the number of consensus client nodes is a positive integer and is not less than 2N / 3, N is an integer and is not less than 2. In this way, the set of encoding fragments corresponding to the block can be stored on the client nodes, and all block data of the block is stored on the client nodes on the blockchain, but each client node only stores a part of the block data of the block, saving the storage space of each client node and improving the storage performance of the blockchain.

[0019] In addition, in the present application, each encoding fragment and its corresponding Merkle tree path are broadcast to each client node for verification between the client nodes based on the encoding fragment and its corresponding Merkle tree path, and it is confirmed whether consensus needs to be formed with the server master node. After the consensus is formed, the set of encoding fragments corresponding to the target block is stored in each consensus client node. That is, after each client node verifies whether the received encoding fragment is correct, the encoding fragment is stored, which can ensure the correctness and accuracy of the encoding fragment stored by each client node.

[0020] In summary, the application optimizes the storage performance of the blockchain on the basis of ensuring the correctness and integrity of the stored transaction data. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only part of the embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of the provided drawings.

[0022] Figure 1 A node architecture of a blockchain disclosed by the present application is shown in the figure;

[0023] Figures 2a-2b An optional signaling flow chart of distributed storage of a blockchain disclosed by the present application is shown in the figure;

[0024] Figure 3 A Merkle tree is shown in the figure as an example of the present application;

[0025] Figure 4 A structure block diagram of a distributed storage device of a blockchain disclosed by the present application is shown in the figure;

[0026] Figure 5 Another structure block diagram of a distributed storage device of a blockchain disclosed by the present application is shown in the figure;

[0027] Figure 6 A hardware structure block diagram of a distributed storage device of a blockchain disclosed by the present application is shown in the figure. DETAILED DESCRIPTION

[0028] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all the 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.

[0029] The distributed storage method of the blockchain provided by the present application can be applied to on-chain storage of the blockchain. Each encoded segment of each block on the blockchain is stored on each client node by the distributed storage method of the blockchain, so as to realize the storage of each block on the blockchain. Storing each block on the blockchain can ensure the security of block data to a certain extent and reduce the risk of data leakage.

[0030] Next, the distributed storage method of the blockchain provided by the present application will be described in detail. Figure 1 An optional blockchain architecture for implementing the distributed storage of the blockchain provided by the present application will be described in detail.

[0031] Referring to Figure 1 The blockchain can include a server master node 10, a client node 20, and a server backup node 30. The nodes on the blockchain are divided into server nodes and client nodes according to types. The server nodes are few in number, and the client nodes are many in number. In the present application, the server nodes store a complete blockchain, which includes block data of each block. The server backup nodes back up each other and keep data synchronization. The client nodes only store encoded fragments of each block and a small amount of Merkle tree data for data integrity verification.

[0032] The server master node 10 exists in the server nodes, and the rest are server backup nodes 30. The client nodes 20 are not divided into master and slave in the present application. There can be a down or malicious client node 20 in multiple client nodes 20. The number of server master nodes 10 is one, the number of server backup nodes 30 is at least one, and the number of client nodes 20 is at least two. The distributed storage method of the blockchain provided in the present application mainly needs the cooperation of the server master node 10 and each client node 20 to realize the storage of each encoded fragment of each block on the blockchain in each client node 20.

[0033] The devices corresponding to the server master node 10 and the server backup node 30 can be service devices, which are realized by a single service device or a server cluster. The devices corresponding to each server node have powerful computing and storage capabilities. The devices corresponding to each client node 20 can be various portable devices, Internet of Things devices, etc., such as iPad, computer, and mobile terminal. The devices corresponding to the client nodes have lower requirements for computing and storage capabilities.

[0034] Each client node 20 can transmit data information to each other, and trust each other. The server master node 10 and the server backup node 20 can also transmit data information to each other. The server master node 10 and each client node 20 can also transmit data information to each other.

[0035] Each client node 20 in the present application can have one or more same or similar attributes.

[0036] The distributed storage method of the blockchain provided in the present application is mainly applied to the server master node and each client node, and the server backup node is mainly used to receive and store all blocks on the blockchain transmitted by the server master node.

[0037] Next, the distributed storage method of the blockchain provided in the embodiments of the present application will be described in detail with reference to Figure 2a and Figure 2b the distributed storage method of the blockchain provided in the embodiments of the present application.Figure 2a and Figure 2b Inherited, the present application is executed in succession Figure 2a and Figure 2b The specific steps of the distributed storage method of the blockchain in the present application are as follows:

[0038] Step S1, the server master node generates a set of encoding fragments corresponding to the target block on the blockchain according to the preset erasure code technology, and a hash value corresponding to each encoding fragment in the set of encoding fragments.

[0039] Specifically, the target block is any unencoded block on the blockchain, for example, it can be any historical block on the blockchain that has not applied the distributed storage method of the blockchain of the present application, or it can be any newly added block on the blockchain that has applied the distributed storage method of the blockchain of the present application.

[0040] The block data in the unencoded target block is in binary form, which needs to be converted into binary first, and then the converted block data is subjected to erasure code technology.

[0041] The erasure code technology can be RS codes (Reed-solomon codes, Reed-Solomon codes), which is a forward error correction channel coding.

[0042] Among them, the number of each encoding fragment in the encoding fragment set corresponding to the target block is the same as the number of client nodes on the blockchain, the encoding fragment set corresponding to the target block contains all the block data of the target block, and after using the erasure code technology, the encoding fragment set corresponding to the target block contains redundant encoding fragments with the same number of tolerable Byzantine nodes. Based on this, only part of the encoding fragments can be obtained to decode the block data of the target block corresponding to the encoding fragment set, wherein the number of part of the encoding fragments is equal to the difference between the number of client nodes on the blockchain and the number of tolerable Byzantine nodes on the blockchain.

[0043] The number of tolerable Byzantine nodes on the blockchain is related to the number of client nodes, if the number of client nodes on the blockchain is a positive integer N, f is the fault tolerance number of consensus nodes set by the Byzantine protocol, f is a non-negative integer, and is equal to Floor[(N-1) / 3], Floor means rounding down.

[0044] A hash algorithm can be used for each encoding fragment to obtain a hash value corresponding to each encoding fragment. Each encoding fragment and each hash value are in a one-to-one correspondence.

[0045] Step S2, the server master node generates a Merkle tree storing the hash values corresponding to the encoded segments, taking the hash values corresponding to the encoded segments as leaf nodes.

[0046] Specifically, the Merkle tree is a binary tree, and each pair of leaf nodes is combined until the hash value of the root node of the Merkle tree is obtained, i.e., the construction of the Merkle tree is completed, as shown in Figure 3 .

[0047] Referring to Figure 3 , each circle represents a node, and the hash value corresponding to each encoded segment in the encoded segment set is the bottom layer of the Merkle tree.

[0048] Step S3, the server master node generates a Merkle tree path corresponding to each encoded segment.

[0049] Specifically, the Merkle tree path corresponding to each encoded segment records all the leaf nodes that need to be passed through from the leaf node corresponding to the encoded segment in the Merkle tree corresponding to the target block to the root node of the Merkle tree.

[0050] Referring to Figure 3 , for example, an encoded segment in the encoded segment set, if the hash value corresponding to the example encoded segment is hash value 2 in Figure 3 , then all the leaf nodes that need to be passed through from the leaf node corresponding to the example encoded segment to the root node of the Merkle tree are the two dashed circles in Figure 3 , and the Merkle tree path is hash value 1 first and then hash value 3.

[0051] Figure 3 The hash values 1, 2, 3, 4, and 5 in

[0052] Step S4, the server master node sends the encoded segment corresponding to the first client node and the Merkle tree path to the first client node.

[0053] Specifically, each encoded segment in the encoded segment set has a corresponding client node, and the server master node can send each encoded segment and its Merkle tree path to the corresponding client node according to the correspondence between the encoded segment and the client node.

[0054] It should be noted that the first client node, the second client node and the third client node in the present application only indicate that the first client node, the second client node and the third client node are three client nodes, and each client node has a unique corresponding encoding segment in the encoding segment set corresponding to the target block, but the present application does not limit the relationship and attributes between the first client node, the second client node and the third client node. The first client node, the second client node and the third client node can have one or more attributes.

[0055] It should also be noted that the implementation steps and optional signaling processes provided in the present application are only for clearly introducing the present application, but the present application is not limited to being used in a blockchain with only three client nodes when implementing the distributed storage method of the blockchain. The number of client nodes is not limited in the present application.

[0056] Step S5, the server master node sends the encoding segment corresponding to the second client node and the Merkle tree path to the second client node.

[0057] Specifically, the server master node sends the encoding segment corresponding to the second client node in the encoding segment set to the second client node, and at the same time, sends the Merkle tree path of the encoding segment corresponding to the second client node.

[0058] Step S6, the server master node sends the encoding segment corresponding to the third client node and the Merkle tree path to the third client node.

[0059] Specifically, the server master node sends the encoding segment corresponding to the third client node in the encoding segment set to the third client node, and at the same time, sends the Merkle tree path of the encoding segment corresponding to the third client node.

[0060] The server master node needs to send each encoding segment in the encoding segment set and its Merkle tree path to the corresponding client node.

[0061] The server master node will not miss any client node in the process of sending the encoding segment, that is, the server master node will also send the corresponding encoding segment to the malicious or down client node.

[0062] Step S7, the server master node sends the target block to the server backup node.

[0063] Specifically, the server master node can send the target block to each server backup node at the same time to backup the target block on the blockchain. The server master node can also directly send all the blocks on the blockchain including the target block to the server backup node to backup all the blocks on the blockchain.

[0064] The steps provided by the embodiment are only for clearly illustrating the present application. In practice, the server master node can execute the steps S4, S5, S6 and S7 in sequence or simultaneously. When the steps S4, S5, S6 and S7 are executed in sequence, the execution order is not necessarily from the step S4 to the step S7. In the implementation process, the present application only pays attention to whether the steps S4, S5, S6 and S7 are completed, and does not pay attention to the execution order of the steps S4, S5, S6 and S7.

[0065] The step S8, the first client node verifies whether the received encoded segment is correct according to the received encoded segment and the Merkle tree path, and stores the encoded segment if correct.

[0066] Specifically, when the first client node receives the encoded segment and the corresponding Merkle tree path, it can verify whether the received encoded segment is correct according to the received encoded segment and the Merkle tree path, and store the received encoded segment if the verification result is correct.

[0067] The verification can be completed by judging whether the received encoded segment is complete.

[0068] In the implementation process, the step S8 is only executed after the step S4, and the present application does not limit whether the step S8 must be executed after the steps S5, S6 and S7.

[0069] The step S9, the second client node verifies whether the received encoded segment is correct according to the received encoded segment and the Merkle tree path, and stores the encoded segment if correct.

[0070] Specifically, when the second client node receives the encoded segment and the corresponding Merkle tree path, it can verify whether the received encoded segment is correct according to the received encoded segment and the Merkle tree path, and store the received encoded segment if the verification result is correct.

[0071] In the implementation process, the step S9 is only executed after the step S5, and the present application does not limit whether the step S9 must be executed after the steps S4, S6, S7 and S8.

[0072] The step S10, the third client node verifies whether the received encoded segment is correct according to the received encoded segment and the Merkle tree path, and stores the encoded segment if correct.

[0073] Specifically, when the third client node receives the encoded segment and its corresponding Merkle tree path, it can verify whether the received encoded segment is correct according to the received encoded segment and Merkle tree path, and store the received encoded segment when the verification result is correct.

[0074] When there is a client node that gets a verification result indicating that the encoded segment is incorrect, the client node can send an instruction to the server master node for the server master node to resend the encoded segment and the Merkle tree path matching the client node.

[0075] In the implementation process, step S10 is only executed after step S6, and the present application does not limit whether step S10 must be executed after steps S4, S5, S7, S8 and S9.

[0076] In the implementation process, there can be malicious or down client nodes on the blockchain, which may not receive the encoded segment after the server master node sends the corresponding encoded segment and Merkle tree path, or may not do any processing after receiving the encoded segment.

[0077] Step S11, the first client node sends the signature and verification result of the first client to the second client node.

[0078] Step S12, the first client node sends the signature and verification result of the first client to the third client node.

[0079] Specifically, after the first client node verifies that the received encoded segment is complete and correct, the first client node signature and verification result are sent to all client nodes in the blockchain except the first client node, which may include malicious or down client nodes.

[0080] The first client node can simultaneously send the signature and verification result of the first client to all client nodes in the blockchain except the first client node.

[0081] The signature and verification result sent by the first client node to all client nodes in the blockchain except the first client node can be consistent.

[0082] Step S13, the second client node sends the signature and verification result of the second client to the third client node.

[0083] Step S14, the second client node sends the signature and verification result of the second client to the first client node.

[0084] Specifically, after the second client node verifies that the received encoded segment is complete and correct, the second client node sends the signature of the second client node and the verification result to all client nodes in the blockchain except the second client node, which can include malicious or down client nodes.

[0085] The second client node can send the signature of the second client and the verification result to all client nodes in the blockchain except the second client node at the same time.

[0086] The signature and verification result sent by the second client node to all client nodes in the blockchain except the second client node can be consistent.

[0087] Step S15, the third client node sends the signature and verification result of the third client to the second client node.

[0088] Step S14, the third client node sends the signature and verification result of the third client to the first client node.

[0089] Specifically, after the third client node verifies that the received encoded segment is complete and correct, the third client node sends the signature of the third client node and the verification result to all client nodes in the blockchain except the third client node, which can include malicious or down client nodes.

[0090] The third client node can send the signature of the third client and the verification result to all client nodes in the blockchain except the third client node at the same time.

[0091] The signature and verification result sent by the third client node to all client nodes in the blockchain except the third client node can be consistent.

[0092] It should be noted that the signatures sent by different client nodes are inconsistent, that is, the signature sent by a client node corresponds to the client node.

[0093] When each client node receives each signature and verification result, it can be decrypted using a pre-set private key.

[0094] Step S17, the first client node judges whether the received signature and verification result is not less than 2N / 3, if yes, step S20 is executed.

[0095] Step S18, the second client node judges whether the received signature and verification result is not less than 2N / 3, if yes, step S21 is executed.

[0096] Step S19, the third client node judges whether the received signature and verification result is not less than 2N / 3, if yes, step S22 is executed.

[0097] Specifically, N is the number of client nodes on the blockchain, N is an integer and not less than 2. Each non-malicious or down client node on the blockchain can count the number of received signatures and verification results after receiving each signature and verification result, if the number of received signatures and verification results is not less than 2N / 3, it can be considered that there are only a small number of malicious and down client nodes on the blockchain, the number of which is less than the number of tolerable Byzantine nodes, at this time, each client node sending the signature and verification result stores the corresponding encoding fragment between each client node.

[0098] If the signature and verification result is less than 2N / 3, there may be too many malicious or down client nodes on the blockchain, at this time, it is necessary to send a reminder message to repair the malicious or down client node or add a new client node.

[0099] Step S20, the first client node sends the confirmation information of the first client node to the server master node.

[0100] Step S21, the second client node sends the confirmation information of the second client node to the first client node.

[0101] Step S22, the third client node sends the confirmation information of the third client node to the second client node.

[0102] Step S23, the first client node sends the confirmation information of the first client node to the second client node.

[0103] Step S24, the second client node sends the confirmation information of the second client node to the third client node.

[0104] Step S25, the first client node sends the confirmation information of the first client node to the third client node.

[0105] Step S26, the second client node sends the confirmation information of the second client node to the server master node.

[0106] Step S27, the third client node sends the confirmation information of the third client node to the first client node.

[0107] Step S28, the third client node sends the confirmation information of the third client node to the server master node.

[0108] Specifically, when each client node receives the signatures and verification results of not less than 2N / 3, the client node sends the confirmation information to the server master node and all the client nodes except the client node, so as to form consensus. For example, the first client node sends the confirmation information of the first client node to the server master node and all the client nodes except the first client node; the second client node sends the confirmation information of the second client node to the server master node and all the client nodes except the second client node; and the third client node sends the confirmation information of the third client node to the server master node and all the client nodes except the third client node.

[0109] The confirmation information includes the signature of the client node sending the confirmation information and the judgment result, and the judgment result indicates that the client node sending the confirmation information receives the signatures and verification results of not less than 2N / 3. For example, the confirmation information of the first client node includes the signature of the first client node and the judgment result.

[0110] After receiving the confirmation information, each client node can analyze the confirmation information to determine the source of each received confirmation information, so as to form consensus among the client nodes sending the confirmation information. Each client node can also determine the client nodes storing the encoded segments of the target block.

[0111] After receiving the confirmation information sent by each client node, the server master node can analyze each received confirmation information to determine whether not less than 2N / 3 client nodes store the encoded segments of the target block.

[0112] It can be seen from the above technical solutions that the nodes on the blockchain include a server master node, at least one server backup node, and at least two client nodes. The distributed storage method of the blockchain provided by the present application is mainly applied to the server master node. First, a set of encoding fragments corresponding to a target block on the blockchain and a hash value corresponding to each encoding fragment in the set of encoding fragments can be generated according to a preset error correction code technology. The number of encoding fragments in the set of encoding fragments corresponding to the target block is the same as the number of client nodes. The set of encoding fragments contains all block data of the target block, and the set of encoding fragments contains redundant encoding fragments with the same number of tolerable Byzantine nodes. Therefore, when all encoding fragments are stored on the blockchain, the storage of all block data of the block can be completed. A Merkle tree that stores the hash values corresponding to the encoding fragments is generated by taking the hash values corresponding to the encoding fragments as leaf nodes. A Merkle tree path corresponding to each encoding fragment is generated. The Merkle tree path corresponding to the encoding fragment records all leaf nodes that need to be passed through from the leaf node corresponding to the encoding fragment in the Merkle tree corresponding to the target block to the root node of the Merkle tree, so that the client nodes can find the hash values on the Merkle tree that match the Merkle tree path based on the Merkle tree path, and verify the integrity and correctness of the received encoding fragments based on this. Each encoding fragment and its corresponding Merkle tree path are broadcast to the corresponding client nodes for verification between the client nodes based on the encoding fragments and their corresponding Merkle tree paths, and it is determined whether consensus needs to be formed with the server master node. After the consensus is formed, the set of encoding fragments corresponding to the target block is stored in each consensus client node. N is the number of client nodes on the blockchain, the number of consensus client nodes is a positive integer and is not less than 2N / 3, N is an integer and is not less than 2. In this way, the set of encoding fragments corresponding to the block can be stored on the client nodes, and all block data of the block is stored on the client nodes on the blockchain, but each client node only stores a part of the block data of the block, saving the storage space of each client node and improving the storage performance of the blockchain.

[0113] In addition, in the present application, each encoding fragment and its corresponding Merkle tree path are broadcast to each client node for verification between the client nodes based on the encoding fragments and their corresponding Merkle tree paths, and it is determined whether consensus needs to be formed with the server master node. After the consensus is formed, the set of encoding fragments corresponding to the target block is stored in each consensus client node. That is, after each client node verifies whether the received encoding fragment is correct, the encoding fragment is stored, which can ensure the correctness and accuracy of the encoding fragments stored by each client node.

[0114] In addition, in the consensus forming process, the broadcasted are the encoding segment, the Merkle tree path, the signature, the verification result and the judgment result, and the Merkle tree does not need to be broadcasted, and the data amount of the encoding segment, the Merkle tree path, the signature, the verification result and the judgment result is small, so that the communication cost and the network bandwidth can be effectively reduced.

[0115] In conclusion, the storage performance of the blockchain is optimized, and the communication cost and the network bandwidth in the consensus process are reduced on the basis of ensuring the correctness and the integrity of the stored transaction data.

[0116] In some embodiments of the present application, considering that new blocks can be added to the blockchain after the consensus is formed, and the new blocks also need to be stored in each client node, each new block can be taken as a target block, and the distributed storage method of the blockchain provided by the present application is executed to realize the distributed storage of the new blocks.

[0117] As can be seen from the above technical solution, the distributed storage method of the blockchain can be used to gradually store the new blocks on the blockchain in each client node in a distributed manner.

[0118] Next, the distributed storage method of the blockchain provided by the present application will be further introduced from the perspective of the server master node.

[0119] In some embodiments of the present application, the process that the server master node generates the encoding segment set corresponding to the target block on the blockchain and the hash value corresponding to each encoding segment in the encoding segment set according to the preset error correction code technology in step S1 is described in detail, and the steps are as follows:

[0120] S10, the server master node divides the block data in the target block according to the error correction code technology, and groups the divided data into a column matrix.

[0121] Specifically, N is the number of client nodes on the blockchain, f is the fault tolerance number of consensus nodes set by the Byzantine protocol, and is a non-negative integer and less than N, the number of elements in the column matrix is equal to N-f, and N is an integer and not less than 2.

[0122] The server master node converts the block data of the target block into binary, divides the binary block data, obtains N-f binary block data segments, and performs operation processing on the block data segments by using the operation rules of the finite field GF(2 8 ).

[0123] S11, the server master node determines the reversible matrix corresponding to each client node on the blockchain.

[0124] Specifically, the reversible matrix can be a Vandermonde matrix or a Cauchy matrix processed by using the operation rules of a finite field GF(2 8 ).

[0125] wherein each client node corresponds to a row vector in the reversible matrix, and the number of elements of each row vector in the reversible matrix is equal to the number of elements in the column matrix.

[0126] S12, the server master node multiplies the reversible matrix by the column matrix to obtain an encoding segment corresponding to each client node, and the encoding segments corresponding to the client nodes form an encoding segment set.

[0127] Specifically, the server master node multiplies the reversible matrix by the column matrix to obtain an encoding segment set, and the number of encoding segments in the encoding segment set is consistent with the number of client nodes on the blockchain. Since each row vector in the reversible matrix corresponds to a client node in a one-to-one manner, and each row vector in the reversible matrix is multiplied by the column matrix to obtain an encoding segment corresponding to the row vector, the encoding segment also corresponds to a client node in a one-to-one manner due to the presence of the row vector in the reversible matrix.

[0128] As can be seen from the above technical solution, compared with the previous embodiment, the present embodiment provides an alternative way to generate an encoding segment set. Through the above process, an encoding segment corresponding to each client node can be generated, thereby realizing distributed storage of the target block. In the process of generating the encoding segment set, a reversible matrix is used, so that the inverse matrix of the reversible matrix can be used to decode the encoding segment to obtain the block data of the target block.

[0129] In some embodiments of the present application, it is considered that after forming a consensus, new client nodes can be added to the blockchain, and the new client nodes also need to store the encoding segments of the target block so as to obtain the encoding segments from the new client nodes in subsequent decoding. Based on this, after the new client nodes join the blockchain that has formed a consensus, the following steps can be added:

[0130] S29, the server master node determines a row vector corresponding to the new client node, and multiplies the row vector corresponding to the new client node by the column matrix to obtain a new encoding segment corresponding to the new client node.

[0131] Specifically, the server master node can determine a row vector corresponding to each new client node. At this time, each client node in the blockchain has a corresponding row vector, and the matrix composed of the row vectors is a reversible matrix. If it is not a reversible matrix, the row vector corresponding to the new client node needs to be determined again.

[0132] The server master node can multiply the row vector corresponding to each new client node with the column matrix composed of the processed block data segments to obtain the encoding segment corresponding to the new client node.

[0133] The encoding segment corresponding to the new client node is a new encoding segment.

[0134] S30, the server master node generates a new hash value corresponding to the new encoding segment.

[0135] Specifically, the server master node can use a hash algorithm to generate a hash value corresponding to the encoding segment of the new client node, and the hash value of the new encoding segment is the new hash value.

[0136] S31, the server master node updates the Merkle tree according to the new hash value and determines a new Merkle tree path corresponding to the new encoding segment.

[0137] Specifically, the server master node can update the Merkle tree corresponding to the target block and determine the Merkle tree path corresponding to the new encoding segment in the updated Merkle tree.

[0138] S32, the server master node sends the new encoding segment and the new Merkle tree path to the corresponding new client node, so that the new client node generates a hash value of the received encoding segment, calculates a root hash value according to the generated hash value and the received Merkle tree path, compares the calculated root hash value with the root hash value of the Merkle tree, and stores the received encoding segment when the calculated root hash value is consistent with the root hash value of the Merkle tree, thereby reducing the impact on the historical encoding segment and the original client node.

[0139] Specifically, the server master node can send the generated new encoding segment and the corresponding Merkle tree path to the corresponding new client node. The new client node generates a hash value of the received encoding segment, and calls the Merkle tree corresponding to the target block to verify the integrity and correctness of the received encoding segment according to the Merkle tree and the received Merkle tree path. When the verification result is correct, the new client node sends confirmation information to the server master node.

[0140] It should be noted that the hash algorithm used by the server master node and each client node to generate the hash value on the blockchain is consistent.

[0141] The encoding rate of the blockchain in the present application is equal to the ratio between the number of block data segments and the number of encoding segments in the encoding segment set, which is also equal to (N-f) / N.

[0142] When the size of a block data is B, the block data is encoded into N encoded fragments, and the encoding rate is equal to (N-f) / N, wherein the block is first divided into N-f parts, and the storage size of each part is B / (N-f). The N-f original data fragments are encoded into N encoded fragments, and the storage size of each encoded fragment is 3B / (2N+1). If the new node is added without changing the number of elements of the row vector, that is, the encoding rate is unchanged, the storage size of the encoded fragment allocated to the new node is also B / (N-f), and the storage size of the encoded fragment obtained by encoding other blocks on the block chain is also unchanged. However, if the number of elements of the row vector is changed, the encoding rate is changed, and the number of real-time client nodes on the block chain is used to determine the reversible matrix and column matrix, then the storage size of each encoded fragment will change to 3B / (2N1+1) after the new node is added, wherein N1 is the number of client nodes on the block chain after the new node is added. Therefore, as the number of client nodes increases, the size of the stored encoded fragment decreases.

[0143] As can be seen from the above technical solution, the embodiment provides a storage method for a target block after a new client node is added to the block chain. Through the above process, after the new client node is added, the encoded fragments do not need to be allocated to each client node on the block chain, and the original client nodes on the block chain are not affected. If the encoded fragments are allocated again according to the number of client nodes on the block chain after the new client node is added, the workload of the server master node is large, the time and communication cost are large, and other services of the server master node are also affected. Therefore, through the technical solution provided by the embodiment, the time and communication cost can be further reduced, and the influence on other services of the server master node can be avoided. In addition, by using the distributed storage method of the block chain provided by the application, the storage amount of the target block can be maintained after the new node is added, and the risk resistance is stronger.

[0144] In some embodiments of the application, the process in which the server master node updates the Merkle tree according to the new hash value in step S31 is described in detail as follows:

[0145] S310, if the number of new client nodes is 1, the Merkle tree is directly updated with the new hash value as a leaf node.

[0146] Specifically, if the number of new client nodes is 1, there is only one new hash value that can be used as a new leaf node. At this time, the new hash value can be directly used as one of the leaf nodes of the Merkle tree corresponding to the target block, and the leaf nodes of the Merkle tree are combined two by two to update the Merkle tree.

[0147] S311, if the number of new client nodes is more than two, a target Merkle tree is generated with each new hash value as a leaf node.

[0148] Specifically, if the number of new client nodes is more than two, the number of new hash values is also more than two, and therefore, the target Merkle tree is generated by combining the new hash values in pairs.

[0149] S312, the root node of the target Merkle tree is combined with the root node of the Merkle tree to obtain an updated Merkle tree.

[0150] Specifically, the target Merkle tree is combined with the original Merkle tree at the root node to complete the update of the root node of the target block.

[0151] From the above technical solution, it can be seen that the embodiment provides an optional way to update the Merkle tree corresponding to the target block. Through the above process, the update of the Merkle tree can be completed to realize that the Merkle tree contains the hash values corresponding to the encoded segments stored by each client node, so that the Merkle tree path for verification can be more accurately generated.

[0152] In some embodiments of the present application, the process of step S2, the server main node generates a Merkle tree storing the hash values corresponding to each encoded segment with the hash values corresponding to each encoded segment as leaf nodes, is described in detail as follows:

[0153] S20, the server main node randomly allocates an identifier to each encoded segment.

[0154] Specifically, the relationship between the encoded segment and the identifier is one-to-one.

[0155] The length of the identifier of each encoded segment can be consistent.

[0156] The server main node can use a random number generation algorithm to generate the identifier of each encoded segment.

[0157] S21, the server main node combines the identifier and the hash value corresponding to the encoded segment into a key-value pair.

[0158] Specifically, the identifier and the hash value of the same encoded segment can be combined and a corresponding relationship is established. The identifier and the hash value are also in a one-to-one relationship.

[0159] S22, the server main node constructs a Merkle tree with each key-value pair corresponding to the encoded segment as a leaf node.

[0160] Specifically, the Merkle tree not only contains the hash value of each encoded segment, but also contains the identification of each encoded segment. The identification and hash value of the same encoded segment form a leaf node of the Merkle tree.

[0161] From the above technical solution, it can be seen that the embodiment provides an optional way to generate a Merkle tree. Through the above method, the identification is one-to-one corresponding to the hash value, and the hash value corresponding to the identification can be obtained by determining the identification. Therefore, the identification corresponding to each hash value in the Merkle tree path can be recorded, and the generation of the Merkle tree path is realized.

[0162] Based on the above embodiment, in some embodiments of the present application, the process of step S3, the server master node generates a Merkle tree path corresponding to each encoded segment, is described in detail as follows:

[0163] S30, the server master node determines the leaf nodes required to be passed through from the leaf node corresponding to each encoded segment to the root node of the Merkle tree.

[0164] Specifically, the server master node starts from each leaf node containing a key-value pair in the Merkle tree, and determines the leaf nodes required to be passed through from the leaf node to the root node of the Merkle tree.

[0165] S31, the server master node obtains the identification in each leaf node required to be passed through in the order of the leaf nodes passed through from the leaf node corresponding to the encoded segment to the root node of the Merkle tree, and forms the Merkle tree path corresponding to the encoded segment.

[0166] Specifically, the server master node obtains the identification in each leaf node required to be passed through in the order of the leaf nodes passed through from the leaf node corresponding to the encoded segment to the root node of the Merkle tree, and forms the Merkle tree path corresponding to the encoded segment.

[0167] From the above technical solution, it can be seen that the embodiment provides an optional way to generate a Merkle tree path corresponding to each encoded segment. Through the above process, the Merkle tree path of each encoded segment can be more accurately generated, so that each client node can be verified.

[0168] Next, the distributed storage method of the blockchain of the present application will be further introduced from the perspective of the client node.

[0169] In some embodiments of the present application, it is considered that after the consensus is formed and the encoding segment corresponding to the target block is stored in each client node, there may be a case of needing to view the transaction data on the target block, etc. which needs to obtain the block data of the target block. At this time, the client node may receive an instruction to obtain the block data. On this basis, the client node can decode, and the decoding process is as follows:

[0170] S33, the client node determines the target number of encoding segments required for decoding.

[0171] Specifically, since the encoding segment set contains f redundant encoding segments, the target number is equal to N-f, where f is the fault tolerance number of the consensus node set by the Byzantine protocol.

[0172] S34, the client node randomly selects N-f-1 target client nodes from other client nodes that have formed a consensus, and obtains the row vector corresponding to the target client node and the encoding segment corresponding to the target block from the target client node, and calls the row vector corresponding to the node and the encoding segment of the target block.

[0173] Specifically, among the client nodes that receive the instruction, if the decoding operation is performed, the client node is not a malicious or down client node, then the client node that receives the instruction has stored an encoding segment corresponding to a target block in advance. At this time, the client node can randomly select N-f-1 target client nodes from the remaining client nodes that have formed a consensus, obtain the row vector corresponding to the target client node and the encoding segment stored by the target client node.

[0174] S35, the client node obtains the block data of the target block by using erasure code decoding technology according to each row vector and each encoding segment.

[0175] Specifically, the client node can obtain the block data of the target block by decoding through erasure code decoding technology and each row vector and each encoding segment.

[0176] In some embodiments of the present application, the process of verifying whether the received encoding segment is correct by the client node according to the received encoding segment and the Merkle tree path is described in detail, and the steps are as follows:

[0177] S40, the client node generates a to-be-verified hash value corresponding to the encoding segment.

[0178] Specifically, if different nodes use the same hash algorithm on the same data information, different nodes can also obtain the same hash value. However, if different nodes use the same hash algorithm on different data information, the hash values obtained by different nodes are not the same. Therefore, it can be determined whether the received encoding segment of the client node is correct by judging whether the hash values are the same. Based on this, the client node can use the hash algorithm on the received encoding segment to obtain the hash value to be verified.

[0179] S41, the client node calls the Merkle tree corresponding to the encoding segment, and finds all the hash values of the leaf nodes between the leaf node corresponding to the encoding segment and the root node in the Merkle tree according to the Merkle tree path.

[0180] Specifically, the client node calls the Merkle tree corresponding to the received encoding segment stored on the blockchain, and finds the hash value in the Merkle tree according to the Merkle tree path.

[0181] S42, the client node generates a root hash value to be verified according to the hash value to be verified and the hash values of all the leaf nodes between the leaf node corresponding to the encoding segment and the root node.

[0182] Specifically, the client node combines the found hash values, and takes the combined hash value as the root hash value to be verified.

[0183] S43, the client node judges whether the root hash value to be verified is consistent with the root hash value of the Merkle tree, and if so, confirms that the received encoding segment is correct.

[0184] Specifically, when the root hash value to be verified is consistent with the root hash value of the Merkle tree, it indicates that the received Merkle tree path and the received encoding segment are corresponding, and the received encoding segment is also complete and correct.

[0185] From the above technical solution, it can be seen that the embodiment provides an optional way to verify whether the received encoding segment is correct. Through the above method, it can be ensured that the encoding segment received by each client node is corresponding to the client node, and the received encoding segment is complete and correct, which can ensure that the stored encoding segment is also correct and complete.

[0186] In some embodiments of the present application, the process of step S35, the client node uses erasure code decoding technology to obtain the block data of the target block according to each row vector and each encoding segment, is described in detail as follows:

[0187] S350, the client node forms an invertible matrix with each row vector, and obtains the inverse matrix of the invertible matrix.

[0188] Specifically, the client node assembles the row vectors into a reversible matrix in a certain order, and obtains an inverse matrix of the reversible matrix.

[0189] If no new client node joins the blockchain before decoding, the reversible matrix here can be part of the reversible matrix used by the server master node when generating the set of encoded segments. The reversible matrix here only contains N-f row vectors, while the reversible matrix used by the server master node when generating the set of encoded segments contains row vectors of all client nodes when generating the set of encoded segments.

[0190] S351, the client node assembles the encoded segments into a column matrix, and the number of rows in the column matrix and the reversible matrix is the same and comes from the same client node.

[0191] Specifically, the client node assembles the encoded segments in the order of assembling the row vectors to obtain the column matrix.

[0192] The encoded segments here can be part of all encoded segments corresponding to the target block generated by the server master node. The encoded segments here only contain N-f encoded segments, while the number of all encoded segments corresponding to the target block generated by the server master node is N.

[0193] S352, the client node multiplies the inverse matrix and the column matrix to obtain the block data of the target block.

[0194] Specifically, the client node multiplies the inverse matrix and the column matrix to obtain a data segment, and processes and integrates the data segment to obtain the block data of the target block.

[0195] As can be seen from the above technical solution, the embodiment provides an optional way to decode to obtain block data. Through the above process, the client node can decode to obtain the block data of the target block after obtaining sufficient row vectors and encoded segments. In this process, only part of the encoded segments and row vectors need to be processed, not all row vectors of the client nodes and all generated encoded segments, saving the amount of calculation and improving the decoding speed. Based on this, all client nodes do not need to be consensus client nodes in the decoding process, allowing malicious or down client nodes to exist in the blockchain, and the application scope is wider.

[0196] The distributed storage device of the blockchain provided by the embodiment of the application is described below. The distributed storage device of the blockchain described below can be referred to in conjunction with the distributed storage method of the blockchain described above.

[0197] First, in combination with the distributed storage method of the blockchain described above, Figure 4The distributed storage device applied to the blockchain corresponding to the device of the server master node is introduced, as shown in Figure 4 The distributed storage device of the blockchain can include:

[0198] The encoding segment set generation unit 11 is configured to generate, according to a preset error correction code technology, an encoding segment set corresponding to a target block on the blockchain and a hash value corresponding to each encoding segment in the encoding segment set, wherein the number of encoding segments in the encoding segment set corresponding to the target block is the same as the number of client nodes, the encoding segment set contains all block data of the target block, and the encoding segment set contains the same number of redundant encoding segments as the number of tolerable Byzantine nodes.

[0199] The Merkle tree generation unit 12 is configured to generate a Merkle tree storing the hash values corresponding to the encoding segments by taking the hash values corresponding to the encoding segments as leaf nodes.

[0200] The Merkle tree path generation unit 13 is configured to generate a Merkle tree path corresponding to each encoding segment, which records all leaf nodes required to be passed through from the leaf node corresponding to the encoding segment to the root node of the Merkle tree in the Merkle tree corresponding to the target block.

[0201] The encoding segment broadcast unit 14 is configured to broadcast each encoding segment and its corresponding Merkle tree path to the corresponding client node, so that each client node verifies and confirms whether to form consensus with the server master node based on the encoding segment and its corresponding Merkle tree path, and stores the encoding segment set corresponding to the target block in each consensus client node after forming consensus, wherein N is the number of client nodes on the blockchain, the number of consensus client nodes is a positive integer and is not less than 2N / 3, N is an integer and is not less than 2.

[0202] First, in combination with Figure 5 The distributed storage device applied to the blockchain corresponding to the device of the server master node is introduced, as shown in Figure 5 The distributed storage device of the blockchain can include:

[0203] The encoding segment receiving unit 21 is configured to receive the encoding segment matched with the node and the Merkle tree path corresponding to the encoding segment sent by the server master node, wherein the encoding segment is obtained by encoding a target block on the blockchain by using a preset erasure code technology, and the Merkle tree path corresponding to the encoding segment records all leaf nodes required to be passed through from a leaf node corresponding to the encoding segment to a root node of the Merkle tree in a Merkle tree corresponding to the target block.

[0204] The encoding segment verifying unit 22 is configured to verify whether the received encoding segment is correct according to the encoding segment and the Merkle tree path corresponding to the encoding segment.

[0205] The encoding segment storing unit 23 is configured to store the received encoding segment if the verification is correct.

[0206] The verification result broadcasting unit 24 is configured to broadcast the signature and the verification result to each client node except the node, so that each client node forms a consensus.

[0207] The number judging unit 25 is configured to judge whether the number of the received signature and the verification result broadcast by each client node except the node is all not less than a threshold value, wherein N is the number of the client nodes on the blockchain, the threshold value is 2N / 3, N is an integer and is not less than 2.

[0208] The confirmation information broadcasting unit 26 is configured to broadcast confirmation information to the server master node and each client node except the node if the number of the signature and the judgment result is all not less than the threshold value, so that the server master node forms a consensus with the client nodes whose number is not less than 2N / 3 after confirming that the number of the confirmation information is not less than the threshold value, to realize that each encoding segment of the target block is stored in each client node forming the consensus.

[0209] The distributed storage device of the blockchain provided by the embodiment of the present application can be applied to a distributed storage device of the blockchain. The distributed storage device of the blockchain can be a device corresponding to the server master node or a device corresponding to the client node. Figure 6 The hardware structure block diagram of the distributed storage device of the blockchain is shown, referring to Figure 6 The hardware structure of the distributed storage device of the blockchain can include at least one processor 1, at least one communication interface 2, at least one memory 3 and at least one communication bus 4.

[0210] In the embodiment of the present application, the number of the processor 1, the communication interface 2, the memory 3 and the communication bus 4 is at least one, and the processor 1, the communication interface 2 and the memory 3 complete the communication among each other through the communication bus 4.

[0211] The processor 1 can be a central processing unit CPU, or an application specific integrated circuit ASIC, or one or more integrated circuits configured to implement embodiments of the present application, etc.

[0212] The memory 3 can include a high-speed RAM memory, and can also include a non-volatile memory, such as at least one disk memory, etc.

[0213] The memory stores a program, and the processor can invoke the program stored in the memory, and the program is used to implement the various processing procedures of the server master node in the distributed storage scheme of the blockchain, or implement the various processing procedures of the client node in the distributed storage scheme of the blockchain.

[0214] The embodiments of the present application also provide a storage medium which can store a program suitable for the processor to execute, and the program is used to implement the various processing procedures of the server master node in the distributed storage scheme of the blockchain, or implement the various processing procedures of the client node in the distributed storage scheme of the blockchain.

[0215] The specific implementation logic of the above-mentioned distributed storage device and storage medium of the blockchain can refer to the related description of the above-mentioned distributed storage method of the blockchain, which will not be repeated here.

[0216] Finally, it should be noted that in this document, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or device including the element.

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

[0218] The above description of disclosed embodiments enables one of ordinary skill in the art to make and use various embodiments of the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Various embodiments of the present application can be combined with each other. Accordingly, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1.A distributed storage method of a blockchain, characterized by, The nodes on the blockchain include one server master node, at least one server backup node, and at least two client nodes, the method is applied to the server master node, and includes: According to the erasure code technology, the block data in the target block is segmented, and the segmented data is composed into a column matrix, wherein N is the number of client nodes on the blockchain, f is the number of fault-tolerant consensus nodes set by the Byzantine protocol, and is a non-negative integer and less than N, the number of elements in the column matrix is equal to N-f, N is an integer and not less than 2; Determine the corresponding reversible matrix of each client node on the blockchain, wherein each client node corresponds to a row vector in the reversible matrix, and the number of elements of each row vector in the reversible matrix is equal to the number of elements in the column matrix; Multiply the reversible matrix and the column matrix to obtain the corresponding encoding segment of each client node, and the corresponding encoding segment of each client node forms an encoding segment set; generate a hash value corresponding to each encoding segment in the encoding segment set, wherein the number of encoding segments in the encoding segment set corresponding to the target block is the same as the number of client nodes, the encoding segment set contains all block data of the target block, and the encoding segment set contains redundant encoding segments with the same number of tolerable Byzantine nodes, L encoding segments record all block data of the target area, and L is equal to the difference between the number of client nodes and the number of tolerable Byzantine nodes; Generate a Merkle tree storing the hash values corresponding to each encoding segment by taking the hash values corresponding to each encoding segment as leaf nodes; Generate a Merkle tree path corresponding to each encoding segment, which records all the leaf nodes that the leaf node corresponding to the encoding segment needs to pass through in the Merkle tree corresponding to the target block to the root node of the Merkle tree; Broadcast each encoding segment and its corresponding Merkle tree path to the corresponding client node, so that each client node verifies based on the encoding segment and its corresponding Merkle tree path, and confirms whether it needs to form a consensus with the server master node, after forming a consensus, the encoding segment set corresponding to the target block is stored in each consensus client node, wherein N is the number of client nodes on the blockchain, the number of consensus client nodes is a positive integer and not less than 2N / 3, N is an integer and not less than 2; If a new client node joins the blockchain, determine the row vector corresponding to the new client node, and multiply the row vector corresponding to the new client node with the column matrix to obtain a new encoding segment corresponding to the new client node; Generate a new hash value corresponding to the new encoding segment; Update the Merkle tree according to the new hash value, and determine a new Merkle tree path corresponding to the new encoding segment; sending the new encoded segment and the new Merkle tree path to a corresponding new client node, so that the new client node generates a hash value of the received encoded segment, and calculates a root hash value according to the generated hash value and the received Merkle tree path, and compares the calculated root hash value with a root hash value of the Merkle tree, and when the calculated root hash value is consistent with the root hash value of the Merkle tree, stores the received encoded segment, so as to reduce the impact on historical encoded segments and original client nodes. 2.The distributed storage method of blockchain according to claim 1, characterized in that, updating the Merkle tree according to the new hash value, including: if the number of new client nodes is one, directly updating the Merkle tree with the new hash value as a leaf node; if the number of new client nodes is more than two, generating a target Merkle tree with each new hash value as a leaf node; combining a root node of the target Merkle tree with a root node of the Merkle tree to obtain an updated Merkle tree. 3.The method of claim 1, wherein, generating a Merkle tree storing hash values corresponding to each encoded segment by taking the hash values corresponding to each encoded segment as leaf nodes, including: randomly assigning an identifier to each encoded segment; the identifier and the hash value corresponding to the encoded segment form a key-value pair; taking the key-value pair corresponding to each encoded segment as a leaf node to construct a Merkle tree. 4.The method of claim 3, wherein, generating a Merkle tree path corresponding to each encoded segment, including: determining the leaf nodes that need to be passed through from the leaf node corresponding to each encoded segment to the root node of the Merkle tree; obtaining the identifiers in the leaf nodes that need to be passed through in the order of the leaf nodes passed through from the leaf node corresponding to the encoded segment to the root node of the Merkle tree to form the Merkle tree path corresponding to the encoded segment. 5.A distributed storage method of a blockchain, characterized in that, The nodes on the blockchain include a server master node, at least one server backup node, and at least two client nodes. The method is applied to a client node and includes: if each client node of the blockchain does not form a consensus of distributed storage of a target block, receiving an encoded segment and a Merkle tree path corresponding to the encoded segment sent by the server master node and matching the node, wherein the encoded segment is obtained by multiplying an invertible matrix and a column matrix by the server master node, the column matrix is obtained by segmenting block data in the target block according to the erasure code technology, N is the number of client nodes on the blockchain, f is the number of fault-tolerant consensus nodes set by the Byzantine protocol, is a non-negative integer and less than N, the number of elements in the column matrix is equal to N-f, N is an integer and not less than 2, each row vector in the invertible matrix corresponds to a client node on the blockchain and the number of elements in each row vector in the invertible matrix is equal to the number of elements in the column matrix, and the Merkle tree path corresponding to the encoded segment records all leaf nodes that need to be passed through from the leaf node corresponding to the encoded segment to the root node of the Merkle tree in the Merkle tree corresponding to the target block; verifying whether the received encoded segment is correct according to the encoded segment and the Merkle tree path corresponding to the encoded segment; If correct, store the received encoded segment; Broadcast the signature and verification result to each client node except the current node, so that each client node forms a consensus; Determine whether the number of received signatures and verification results broadcast by each client node except the current node is not less than a threshold, wherein N is the number of client nodes on the blockchain, and the threshold is 2N / 3, N is an integer and not less than 2; If the number of signatures and verification results is not less than the threshold, broadcast confirmation information to the server master node and the client nodes except the current node, so that the server master node forms a consensus with the client nodes whose number is not less than 2N / 3 after confirming that the number of confirmation information is not less than the threshold, to realize that each encoded segment of the target block is stored in each client node that forms a consensus, and the L encoded segments corresponding to the target block are recorded in all block data of the target area, L is equal to the difference between N and the number of tolerable Byzantine nodes; If each client node of the blockchain has formed a consensus to distribute the target block, receive the encoded segment and the corresponding Merkle tree path sent by the server master node, wherein the encoded segment is obtained by multiplying the row vector corresponding to the client node by the column matrix, and the Merkle tree path is obtained by updating the Merkle tree based on the hash value corresponding to the current node generated by the server master node, and the Merkle tree is constructed based on the hash value of each encoded segment corresponding to the client node that has formed a consensus; Generate a hash value of the received encoded segment, and calculate a root hash value according to the generated hash value and the received Merkle tree path, and compare the calculated root hash value with the root hash value of the Merkle tree, and store the received encoded segment when the calculated root hash value is consistent with the root hash value of the Merkle tree. 6.The method of claim 5, wherein, According to the encoded segment and the corresponding Merkle tree path, verify whether the received encoded segment is correct, comprising: Generating a to-be-verified hash value corresponding to the encoded segment; Calling the Merkle tree corresponding to the encoded segment, finding all leaf node hash values between the leaf node corresponding to the encoded segment and the root node in the Merkle tree according to the Merkle tree path; Generating a to-be-verified root hash value according to the to-be-verified hash value and all leaf node hash values between the leaf node corresponding to the encoded segment and the root node; Determine whether the to-be-verified root hash value is consistent with the root hash value of the Merkle tree, and if so, confirm that the received encoded segment is correct. 7.The method of claim 5, wherein, After realizing that each encoded segment of the target block is stored in each client node that forms a consensus, further comprising: If it is necessary to obtain the block data on the target block, determine the target number of encoded segments required for decoding, wherein f is the fault tolerance number of consensus nodes set by the Byzantine protocol, and is a non-negative integer less than N, and the target number is equal to N-f; Randomly selecting N-f-1 target client nodes from other consensus-forming client nodes, and obtaining the row vector corresponding to the target client node and the encoding segment corresponding to the target block from the target client node, and calling the row vector corresponding to the node and the encoding segment of the target block; According to each row vector and each encoding segment, the block data of the target block is obtained by using the erasure code decoding technology. 8.The method of claim 7, wherein, According to each row vector and each encoding segment, the block data of the target block is obtained by using the erasure code decoding technology, including: Each row vector is combined to form an invertible matrix, and an inverse matrix of the invertible matrix is obtained; Each encoding segment is combined to form a column matrix, and the column matrix and the elements with the same number of rows in the invertible matrix come from the same client node; The inverse matrix is multiplied by the column matrix to obtain the block data of the target block.

Images