Block storage method, system, device and server based on distributed hash

Abstract

This application relates to the field of blockchain technology, and in particular to a block storage method, system, device, and server based on distributed hashing. The method is applied to a non-consensus node cluster and includes: a first non-consensus node in the non-consensus node cluster synchronizes the to-be-stored blocks in the block list from the consensus node, and synchronously stores the block headers of the to-be-stored blocks in all non-consensus nodes within the non-consensus node cluster. The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node; the first non-consensus node determines the first target non-consensus nodes corresponding to the to-be-stored blocks in the block list according to the distributed hashing algorithm and the node routing table corresponding to the non-consensus node cluster, and stores the block bodies of the to-be-stored blocks in the first target non-consensus nodes corresponding to the to-be-stored blocks. Using this method can effectively reduce the query pressure on the VP and the storage pressure on the NVP, and reduce the overall storage cost of the system.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a block storage method, system, device, and server based on distributed hashing. Background Art

[0002] A blockchain is a distributed system based on a P2P network. All nodes jointly maintain the blockchain network without a centralized control agency. Due to the characteristics of decentralization and immutability of the blockchain, blockchain technology has developed rapidly and is widely applied in various fields. In the blockchain architecture of a consortium chain, when deploying consensus nodes (Validating Peer, VP), some non-consensus nodes (None-Validating Peer, NVP) are usually deployed at the same time, aiming to reduce the query burden of consensus nodes and optimize performance. VPs need to participate in the block consensus process, and NVPs do not need to participate in the block consensus process. However, in order to maintain the consistency of data in blockchain nodes, although these NVPs do not participate in the consensus process, they need to synchronize and store all block data of VPs to provide query services externally.

[0003] However, this full synchronization storage method causes NVPs to face huge storage pressure and requires a high storage capacity for a single NVP. In addition, multiple NVPs all store complete block data, resulting in a high storage cost for the entire system.

[0004] In view of this, how to effectively reduce the query pressure of VPs and the storage pressure of NVPs and reduce the overall storage cost of the system is an urgent problem to be solved currently. Summary of the Invention

[0005] In view of this, embodiments of this application provide a block storage method, system, device, and server based on distributed hashing, which can effectively reduce the query pressure of VPs and the storage pressure of NVPs and reduce the overall storage cost of the system.

[0006] The first aspect of the embodiments of this application provides a block storage method based on distributed hashing, which is applied to a non-consensus node cluster. The method includes:

[0007] A first non-consensus node in the non-consensus node cluster synchronizes the to-be-stored blocks in the block list from a consensus node, and synchronously stores the block headers of the to-be-stored blocks in all non-consensus nodes in the non-consensus node cluster. The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node;

[0008] The first non-consensus node determines the first target non-consensus nodes corresponding to the blocks to be stored in the block list according to the node routing table corresponding to the non-consensus node cluster by means of the distributed hash algorithm, and stores the block bodies of the blocks to be stored in the first target non-consensus nodes corresponding to the blocks to be stored respectively.

[0009] In a possible implementation manner of the first aspect, the first non-consensus node determines the first target non-consensus nodes corresponding to the blocks to be stored in the block list according to the node routing table corresponding to the non-consensus node cluster by means of the distributed hash algorithm, including:

[0010] When the block to be stored synchronized by the first non-consensus node is a checkpoint block, the first non-consensus node calculates the distance value between the first non-consensus node and the checkpoint block according to the node ID of the first non-consensus node and the hash value corresponding to the checkpoint block;

[0011] The first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its co-segment blocks according to the distance value and the node routing table, where the co-segment blocks refer to the blocks to be stored in the block list between the checkpoint block and its previous checkpoint block, and the first target non-consensus nodes corresponding to the checkpoint block and its co-segment blocks are the same;

[0012] The storing the block bodies of the blocks to be stored in the first target non-consensus nodes corresponding to the blocks to be stored respectively includes:

[0013] Pack and store the block bodies of the checkpoint block and its co-segment blocks in the block list together in the first target non-consensus node.

[0014] In a possible implementation manner of the first aspect, the node routing table includes the node information of several bucket non-consensus nodes and the distance interval corresponding to each bucket;

[0015] The first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its co-segment blocks according to the distance value and the node routing table, including:

[0016] The first non-consensus node determines the distance interval to which the distance value belongs in the node routing table;

[0017] The first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its co-segment blocks according to the node information of the non-consensus nodes in the bucket corresponding to the belonging distance interval.

[0018] In a possible implementation manner of the first aspect, the method further includes:

[0019] The second non-consensus node in the non-consensus node cluster receives a query request sent by the client, and the second non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the client;

[0020] Based on the node routing table, the second non-consensus node determines a second target non-consensus node corresponding to the query request, and instructs the second target non-consensus node to process the query request;

[0021] The second non-consensus node sends the query result obtained by the second target non-consensus node processing the query request to the client.

[0022] In a possible implementation manner of the first aspect, the query request carries a query type and a target block header of a target block; based on the node routing table, the second non-consensus node determines a second target non-consensus node corresponding to the query request, and instructs the second target non-consensus node to process the query request, including:

[0023] The second non-consensus node determines whether the target block header exists in the non-consensus node cluster;

[0024] If the target block header exists in the non-consensus node cluster, the second non-consensus node is the second target consensus node, and the second non-consensus node determines whether a target block body corresponding to the target block header exists locally on the second non-consensus node;

[0025] If the target block body exists locally on the second non-consensus node, the second non-consensus node determines a target query result according to the query type and the target block body, and feeds back the target query result to the client.

[0026] In a possible implementation manner of the first aspect, the second non-consensus node determines a second target non-consensus node corresponding to the query request according to the node routing table, and instructs the second target non-consensus node to process the query request, further including:

[0027] If the target block body does not exist locally on the second non-consensus node, the second non-consensus node determines a target checkpoint block corresponding to the target block, and the target checkpoint block is a co-segment block of the target block;

[0028] The second non-consensus node calculates a target distance value between the second non-consensus node and the target checkpoint block according to the node ID of the second non-consensus node and the hash value corresponding to the target checkpoint block;

[0029] The second non-consensus node determines a second target non-consensus node corresponding to the target checkpoint block according to the target distance value and the node routing table;

[0030] The second non-consensus node forwards the query request to the second target non-consensus node;

[0031] Receives a query result corresponding to the query request fed back by the second target non-consensus node, and sends the query result to the client.

[0032] In a possible implementation manner of the first aspect, before the first non-consensus node determines a first target non-consensus node corresponding to each block to be stored in the block list according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, it further includes:

[0033] The non-consensus node cluster calculates node distance values between non-consensus nodes in the non-consensus node cluster according to the node IDs of non-consensus nodes in the non-consensus node cluster;

[0034] The non-consensus node cluster performs hierarchical processing on non-consensus nodes in the non-consensus node cluster based on the node distance values, and determines a number of buckets according to the hierarchical processing result, where each bucket contains non-consensus nodes within a distance range;

[0035] The non-consensus node cluster constructs a node routing table corresponding to the non-consensus node cluster based on the number of buckets.

[0036] In the embodiments of the present application, each non-consensus node in the non-consensus node cluster stores the block headers of all blocks, and the block body of the block is distributedly stored in the first target non-consensus node corresponding to each block according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, which can effectively reduce the storage pressure of a single non-consensus node, and further reduce the storage cost of the entire system. At the same time, since each non-consensus node stores the block headers of all blocks, it helps the client to send a query request to any non-consensus node in the non-consensus node cluster, and the non-consensus node cluster can process the query request. The client does not need to send a query request to the consensus node, which can effectively reduce the query pressure of the consensus node, and further improve the performance and reliability of the system.

[0037] A second aspect of the embodiments of the present application provides a block storage system based on distributed hashing. The system includes a consensus node and a non-consensus node cluster. The non-consensus node cluster includes a first non-consensus node, and the first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node; where:

[0038] The consensus node is used to synchronize the blocks to be stored in the block list with the first non-consensus node;

[0039] The first non-consensus node is used to synchronize the blocks to be stored in the block list from the consensus node, and synchronously store the block headers of the blocks to be stored in all non-consensus nodes in the non-consensus node cluster. The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node; according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, determine the first target non-consensus node corresponding to each block to be stored in the block list, and store the block bodies of the blocks to be stored in the first target non-consensus node corresponding to each block to be stored.

[0040] A third aspect of the embodiments of the present application provides a block storage device based on distributed hash, which is applied to a non-consensus node cluster. The device includes:

[0041] A block synchronization unit, configured to enable the first non-consensus node in the non-consensus node cluster to synchronize the blocks to be stored in the block list from the consensus node, and synchronously store the block headers of the blocks to be stored in all non-consensus nodes in the non-consensus node cluster. The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node;

[0042] A block storage unit, configured to enable the first non-consensus node to determine the first target non-consensus node corresponding to each block to be stored in the block list according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, and store the block bodies of the blocks to be stored in the first target non-consensus node corresponding to each block to be stored.

[0043] A fourth aspect of the embodiments of the present application provides a server, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, the steps of the block storage method based on distributed hash provided in the first aspect of the embodiments of the present application are implemented.

[0044] A fifth aspect of the embodiments of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps of the block storage method based on distributed hash provided in the first aspect of the embodiments of the present application are implemented.

[0045] A sixth aspect of the embodiments of the present application provides a computer program product. When the computer program product runs on a server, the server is enabled to execute the steps of the block storage method based on distributed hash described in the first aspect of the embodiments of the present application.

[0046] It is understandable that the beneficial effects of the above-mentioned second to sixth aspects can be referred to the relevant descriptions in the first aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0048] Figure 1.1 is a system architecture diagram of a block storage system based on distributed hash provided by an embodiment of the present application;

[0049] Figure 1.2 is another system architecture diagram of a block storage system based on distributed hash provided by an embodiment of the present application;

[0050] Figure 2 is an implementation flowchart of a block storage method based on distributed hash provided by an embodiment of the present application;

[0051] Figure 3 is a schematic diagram of block segmentation in a block storage method based on distributed hash provided by an embodiment of the present application;

[0052] Figure 4.1 is a specific implementation flowchart of constructing a node routing table corresponding to a non-consensus node cluster in a block storage method based on distributed hash provided by an embodiment of the present application;

[0053] Figure 4.2 is a schematic diagram of a node routing table in a block storage method based on distributed hash provided by an embodiment of the present application;

[0054] Figure 5 is a schematic diagram of an application scenario of a block query method based on distributed hash provided by an embodiment of the present application;

[0055] Figure 6 is a schematic diagram of an application scenario of a block storage method based on distributed hash provided by an embodiment of the present application;

[0056] Figure 7.1 is a structural block diagram of a block storage device based on distributed hash provided by an embodiment of the present application;

[0057] Figure 7.2 is another structural block diagram of a block storage device based on distributed hash provided by an embodiment of the present application;

[0058] Figure 8 Schematic diagram of a server provided by an embodiment of the present application. Specific implementation manners

[0059] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system architectures, technologies, etc. are presented to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0060] In addition, in the description of the specification of the present application and the appended claims, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0061] The reference to "one embodiment" or "some embodiments" etc. described in the specification of the present application means that specific features, structures, or characteristics described in connection with the embodiment are included in one or more embodiments of the present application. Thus, the statements "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "include", "comprise", "have" and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0062] In some blockchain networks, consensus nodes and non-consensus nodes are deployed simultaneously. The consensus nodes are responsible for the creation and verification of blocks and maintaining the security and consistency of the entire blockchain; the non-consensus nodes are mainly used for data querying and storage to assist in improving the overall performance of the network. The current existing blockchain non-consensus node data storage schemes are mainly divided into two types. The first scheme is to synchronize all block data of the consensus nodes in full. The non-consensus nodes completely synchronize all block data from the consensus nodes, including transaction details. The second scheme is that the non-consensus nodes only synchronize the block header information without including specific transaction details. For the first scheme, each non-consensus node needs to store the complete blockchain data, which requires a relatively high storage capacity for a single node. Moreover, when multiple non-consensus nodes synchronize all block data in full, there will be a large amount of data redundancy in the network, and the system redundancy storage cost is high. For the second scheme, although the storage pressure on the non-consensus nodes is reduced, when transaction details need to be queried, the non-consensus nodes still need to send requests to the consensus nodes, which does not really relieve the query pressure on the consensus nodes and may also reduce the overall performance of the network.

[0063] In view of the above problems, the embodiments of the present application provide a block storage method, system, device, and server based on distributed hashing. The method is applied to a non-consensus node cluster. The first non-consensus node in the non-consensus node cluster synchronizes the blocks to be stored in the block list from the consensus node, and synchronously stores the block headers of the blocks to be stored in all non-consensus nodes in the non-consensus node cluster. At the same time, according to the distributed hashing algorithm and the node routing table corresponding to the non-consensus node cluster, the first target non-consensus nodes corresponding to the blocks to be stored in the block list are determined, and the block bodies of the blocks to be stored are stored in the first target non-consensus nodes corresponding to the blocks to be stored. The solution of the present application can achieve distributed storage of blocks, without the need for each non-consensus node to synchronize all block data in full, effectively reducing the storage pressure on a single non-consensus node cluster in the system, and further reducing the storage cost of the entire system. At the same time, since each non-consensus node stores the block headers of all blocks, it helps the client to send a query request to any non-consensus node in the non-consensus node cluster, and the non-consensus node cluster can process the query request. The client does not need to send a query request to the consensus node, which can effectively reduce the query pressure on the consensus node.

[0064] It should be understood that each method embodiment of the present application provides a block storage method based on distributed hashing applicable to various types of terminal devices or servers that require blockchain storage, specifically including terminal devices such as mobile phones, tablet computers, wearable devices, notebook computers, ultra-mobile personal computers (UMPCs), and desktop computers. The embodiments of the present application do not impose any restrictions on the specific types of terminal devices and servers.

[0065] In order to illustrate the technical solutions described in the present application, the following will be described through specific embodiments.

[0066] Figure 1.1 The system architecture diagram of a block storage system based on distributed hashing provided by the embodiments of the present application is shown and described in detail as follows: For the sake of convenience of description, only the parts related to the embodiments of the present application are shown.

[0067] Refer to Figure 1.1 , the block storage system based on distributed hashing includes a consensus node 1 and a non-consensus node cluster 2. The non-consensus node cluster 2 includes a plurality of interconnected non-consensus nodes, and among the plurality of non-consensus nodes, there is a first non-consensus node 2-1, and the first non-consensus node 2-1 is any non-consensus node in the non-consensus node cluster 2 that is connected to the consensus node 1; where:

[0068] The first non-consensus node 2-1 synchronizes the to-be-stored blocks in the block list from the consensus node 1, and stores the block headers of the to-be-stored blocks in all non-consensus nodes within the non-consensus node cluster 2.

[0069] The first non-consensus node 2-1 determines the first target non-consensus nodes corresponding to the to-be-stored blocks in the block list according to the node routing table corresponding to the non-consensus node cluster 2, and stores the block bodies of the to-be-stored blocks in the first target non-consensus nodes corresponding to the to-be-stored blocks.

[0070] As a possible implementation manner of this application, as Figure 1.2 shown, the block storage system based on distributed hash further includes a client 3. The non-consensus node cluster 2 includes a second non-consensus node 2-2, and the second non-consensus node 2-2 is any non-consensus node in the non-consensus node cluster 2 that is connected to the client 3; wherein:

[0071] The client is used to send a query request to the second non-consensus node;

[0072] The second non-consensus node is used to receive the query request sent by the client; determine the second target non-consensus node corresponding to the query request according to the node routing table, instruct the second target non-consensus node to process the query request; and send the query result to the client.

[0073] In the embodiment of this application, the first non-consensus node 2-1 and the second non-consensus node 2-2 may be the same non-consensus node in the non-consensus node cluster. In this case, this non-consensus node is both connected to the consensus node 1 and also connected to the client 3.

[0074] As the scale of the consortium chain network expands, deploying multiple non-consensus nodes can effectively expand the query ability and support more users to query blockchain data simultaneously. By constructing the non-consensus node cluster 2, any non-consensus node in the non-consensus node cluster 2 can be used as the first non-consensus node 2-1, representing other non-consensus nodes in the non-consensus node cluster 2 to connect and communicate with the consensus node 1, and other non-consensus nodes in the non-consensus node cluster 2 are all connected to the first non-consensus node 2-1.

[0075] On the one hand, the first non-consensus node 2-1 synchronizes the to-be-stored blocks in the block list from the consensus node 1. The first non-consensus node 2-1 synchronously stores the block headers of the to-be-stored blocks in the block list in other non-consensus nodes in the non-consensus node cluster 2, that is, each non-consensus node in the non-consensus node cluster synchronously stores the block headers, ensuring the full storage of the block headers in the non-consensus node cluster and at the same time facilitating the client to query through the non-consensus node.

[0076] On the other hand, the first non-consensus node 2-1 determines the first target non-consensus nodes corresponding to the to-be-stored blocks in the block list according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, and distributes and stores the block bodies of the to-be-stored blocks to the first target non-consensus nodes corresponding to the to-be-stored blocks, realizing the distributed allocation of the block bodies. It is not necessary for all non-consensus nodes in the non-consensus node cluster 2 to synchronously store all block bodies, effectively reducing the storage pressure on a single non-consensus node, and further reducing the storage cost of the entire system.

[0077] In a possible implementation manner, the first non-consensus node 2-1 may be connected to only one consensus node 1, or the first non-consensus node 2-1 may be connected to more than one consensus node 1.

[0078] In a possible implementation manner, there may be more than one first non-consensus node 2-1 in the non-consensus node cluster 2. The first non-consensus node 2-1 is connected to only one consensus node 1, and the non-consensus node cluster 2 is connected to multiple consensus nodes 1 through multiple first non-consensus nodes 2-1.

[0079] Exemplarily, VP1 is connected to NVP1 in the NVP cluster. NVP1 synchronizes the to-be-stored blocks in the VP1 block list, synchronously stores the block headers of the to-be-stored blocks in the VP1 block list in all NVPs in the NVP cluster. The NVP determines the storage nodes (non-consensus nodes in the NVP cluster) corresponding to the to-be-stored blocks in the block list according to the distributed hash algorithm and the node routing table corresponding to the NVP cluster, and stores the block bodies of the to-be-stored blocks in the VP1 block list to the storage node. VP2 is connected to NVP2 in the NVP cluster. NVP2 synchronizes the to-be-stored blocks in the VP2 block list, synchronously stores the block headers of the to-be-stored blocks in the VP2 block list in all NVPs in the NVP cluster. The NVP determines the storage nodes (non-consensus nodes in the NVP cluster) corresponding to the to-be-stored blocks in the block list according to the distributed hash algorithm and the node routing table corresponding to the NVP cluster, and stores the block bodies of the to-be-stored blocks in the VP2 block list to the storage node. Both NVP1 and NVP2 are the first non-consensus nodes in this embodiment.

[0080] In the embodiments of the present application, each non-consensus node in the non-consensus node cluster stores the block headers of all blocks, and the block bodies of the blocks are distributedly stored in the first target non-consensus nodes corresponding to the blocks according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, which can effectively reduce the storage pressure of a single non-consensus node, thereby reducing the storage cost of the entire system. At the same time, since each non-consensus node stores the block headers of all blocks, it helps the client to send a query request to any non-consensus node in the non-consensus node cluster. The non-consensus node cluster can process the query request, and the client does not need to send a query request to the consensus node, which can effectively reduce the query pressure on the consensus node, and thus improve the performance and reliability of the system.

[0081] Figure 2 The figure shows the implementation process of the block storage method based on distributed hash provided by the embodiments of the present application. The embodiments of the present application are applied to a non-consensus node cluster, and the method process may include the following steps S201 to step S202. The specific implementation principles of each step are as follows:

[0082] Step S201: The first non-consensus node in the non-consensus node cluster synchronizes the to-be-stored block in the block list from the consensus node, and synchronously stores the block header of the to-be-stored block in all non-consensus nodes in the non-consensus node cluster.

[0083] The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node.

[0084] When the consensus nodes verify a group of transactions and reach a consensus, they will package these transactions into a new block and broadcast it to other nodes in the whole network. This new block contains all the verified transaction records, as well as information such as the block header and the hash value of the previous block. In this embodiment, the non-consensus node cluster obtains the latest block data from the consensus node through the first non-consensus node to keep in sync with the blockchain network. Although the nodes in the consensus node cluster do not participate in the consensus, they are equally important for the distributed storage and transaction verification of the blockchain.

[0085] The to-be-stored block mentioned above is the new block verified by the first non-consensus node. In the embodiments of the present application, after receiving the new block sent by the consensus node, the first non-consensus node will verify it. If the verification is passed, the first non-consensus node will add the block header of this new block to its local ledger, and at the same time, synchronously send the block header of this new block to other non-consensus nodes in the non-consensus node cluster for storage. This process can ensure that each non-consensus node in the non-consensus node cluster stores the block header of the new block.

[0086] Step S202: The first non-consensus node determines the first target non-consensus nodes corresponding to the to-be-stored blocks in the block list according to the node routing table corresponding to the non-consensus node cluster based on the distributed hash algorithm, and stores the block bodies of the to-be-stored blocks in the first target non-consensus nodes corresponding to the to-be-stored blocks respectively.

[0087] The first target non-consensus node is the non-consensus node that stores the to-be-stored block. There is more than one first target non-consensus node. Different to-be-stored blocks may correspond to the same first target non-consensus node or different first target non-consensus nodes.

[0088] The addition of non-consensus nodes helps to disperse the load of the entire blockchain network and improve the query performance and user experience of the entire consortium blockchain network. In the embodiment of the present application, based on the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, the block bodies of the to-be-stored blocks synchronized from the consensus nodes are distributedly stored in the first target non-consensus nodes corresponding to the to-be-stored blocks, which can effectively reduce the storage pressure on a single non-consensus node in the non-consensus node cluster and effectively reduce the storage cost of the entire system.

[0089] As a possible implementation manner of the present application, when the to-be-stored block synchronized by the first non-consensus node is a checkpoint block, the first non-consensus node calculates the distance value between the first non-consensus node and the checkpoint block according to the node ID of the first non-consensus node and the hash value corresponding to the checkpoint block. The first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks according to the distance value and the node routing table. The same-segment block refers to the to-be-stored block between the checkpoint block and its previous checkpoint block in the block list, and the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks are the same. The block bodies of the checkpoint block and its same-segment blocks in the block list are packaged and stored in the first target non-consensus node together.

[0090] In this embodiment, if the current first non-consensus node is the first target non-consensus node, the same-segment blocks of the checkpoint block are directly stored locally; if the current first non-consensus node is not the first target non-consensus node, the same-segment blocks of the checkpoint block are packaged and sent to the corresponding first target non-consensus node.

[0091] Exemplarily, taking an application scenario as an example, such as Figure 3The block list shown includes block1-block6. The block list is segmented according to checkpoint 1 and checkpoint 2. Block1 and block2 are the same-segment blocks of checkpoint 1 block3, and block4 and block5 are the same-segment blocks of checkpoint 2 block6. When synchronized to block3, block3 is a checkpoint. At this time, block1, block2 and block3 are packaged together and sent to the first target non-consensus node. When synchronized to block6, block6 is also a checkpoint. At this time, block4, block5 and block6 are packaged together and sent to the first target non-consensus node.

[0092] The node routing table includes node information of several bucket non-consensus nodes and a distance interval corresponding to each bucket. The first non-consensus node determines the distance interval to which the distance value belongs in the node routing table; the first non-consensus node determines the first target non-consensus node corresponding to the check node block and its same-segment block based on the node information of the non-consensus nodes in the bucket corresponding to the distance interval.

[0093] In a possible implementation, there may be more than one non-consensus node in each bucket. To avoid failure of a non-consensus node resulting in inability to query, in an embodiment of the present application, there may be more than one non-consensus node storing the same block to be stored. That is, there may be more than one first target non-consensus node corresponding to the same block to be stored. More than one non-consensus node is selected from the bucket corresponding to the distance value as the first target non-consensus node, and the block body of the block to be stored is stored at the same time. In this embodiment, redundant backup of block data is supported, which can enhance the fault tolerance of the system.

[0094] As a possible implementation of this application, Figure 4.1 A specific implementation process of constructing a node routing table corresponding to a non-consensus node cluster in a distributed hash-based block storage method provided in an embodiment of the present application is shown, and is described in detail as follows:

[0095] A1: The non-consensus node cluster calculates the node distance value between each non-consensus node in the non-consensus node cluster according to the node ID of each non-consensus node in the non-consensus node cluster.

[0096] Each non-consensus node has a unique node ID, which is a hash value calculated using a hash algorithm for node information such as node name, IP address, port, etc. The node distance value between two non-consensus nodes can be the XOR distance value of the node IDs of the two non-consensus nodes.

[0097] A2: The non-consensus node cluster performs hierarchical processing on the non-consensus nodes in the non-consensus node cluster based on the node distance values, and determines several buckets according to the hierarchical processing results. Each bucket contains non-consensus nodes within a distance interval. Each bucket corresponds to a distance interval.

[0098] A3: The non-consensus node cluster constructs a node routing table corresponding to the non-consensus node cluster based on the several buckets. The node routing table includes the distance values between each non-consensus node and other consensus nodes.

[0099] In this embodiment, the above hierarchical processing process and the process of constructing the node routing table are based on the Kademlia algorithm, which is a distributed storage and routing algorithm. By searching through the node routing table constructed based on the Kademlia algorithm, the search range can be shrunk like continuously folding a piece of paper. It is ensured that for any n non-consensus nodes, it is only necessary to query log2(n) times at most to find the target non-consensus node, which can effectively improve the storage and query efficiency.

[0100] In a possible implementation manner, in order to limit the size of the node routing table and avoid the node routing table from being too large, the size of each bucket is set to K, and the value of K can be custom-set according to requirements.

[0101] Exemplarily, Figure 4.2 shows a schematic diagram of a routing table. This routing table takes node 6 as the main perspective and shows the XOR distance between other NVPs and node 6. Figure 4.2 There are 3 buckets. Among them, K being 2 means that the number of non-consensus nodes in each bucket does not exceed 2. In Figure 4.2 , the XOR distance between NVP(7) and NVP(6) is 1 (110 XOR 110), the XOR distance between NVP(4) and NVP(6) is 2 (100 XOR 110), the XOR distance between NVP(5) and NVP(6) is 3 (101 XOR 110), the XOR distance between NVP(0) and NVP(6) is 6 (000 XOR 110), the XOR distance between NVP(1) and NVP(6) is 7 (001 XOR 110), the XOR distance between NVP(2) and NVP(6) is 4 (010 XOR 110), and the XOR distance between NVP(3) and NVP(6) is 5 (011 XOR 110). For the 3rd bucket, the number of nodes exceeds the K value, and the 2 extra nodes NVP(2) and NVP(3) are used as alternative nodes.

[0102] As a possible implementation manner of this application, Figure 5The implementation process of the block query method based on distributed hash provided by the embodiments of the present application is shown. The embodiments of the present application are applied to a non-consensus node cluster, and the method process may include the following steps S501 to step S503. The specific implementation principles of each step are as follows:

[0103] Step S501: The second non-consensus node in the non-consensus node cluster receives a query request sent by the client.

[0104] In this embodiment, the second non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the client. The second non-consensus node receives the query request sent by the client.

[0105] Step S502: The second non-consensus node determines a second target non-consensus node corresponding to the query request based on the node routing table, and instructs the second target non-consensus node to process the query request.

[0106] The query request carries a query type and a target block header of the target block. In this embodiment, the query type includes querying block information and querying transaction information. If the query type carried by the query request is querying block information, the block information of the target block is fed back to the client; if the query type carried by the query request is querying transaction information, the transaction information in the target block is fed back to the client.

[0107] As a possible implementation manner of the present application, the second non-consensus node determines whether the target block header exists in the non-consensus node cluster; if the target block header exists in the non-consensus node cluster, the second non-consensus node is the second target consensus node, and the second non-consensus node determines whether the target block body corresponding to the target block header exists locally in the second non-consensus node; if the target block body exists locally in the second non-consensus node, the second non-consensus node determines a target query result according to the query type and the target block body, and feeds back the target query result to the client.

[0108] If the target block header does not exist in the non-consensus node cluster, the second non-consensus node feeds back that the query result does not exist to the client. In this embodiment, the block header of each block is stored in each non-consensus node in the non-consensus node cluster. When the second non-consensus node receives a query request from the client, it queries locally whether the target block header of the target block requested by the client exists, and determines whether the target block exists in the non-consensus node cluster. If not, it directly feeds back to the client that the query result does not exist.

[0109] As a possible implementation manner of the present application, if the target block body does not exist locally at the second non-consensus node, the second non-consensus node determines a target checkpoint block corresponding to the target block, and the target checkpoint block is a checkpoint block in the same segment as the target block; the second non-consensus node calculates a target distance value between the second non-consensus node and the target checkpoint block according to the node ID of the second non-consensus node and the hash value corresponding to the target checkpoint block; the second non-consensus node determines a second target non-consensus node corresponding to the target checkpoint block according to the target distance value and the node routing table; the second non-consensus node forwards the query request to the second target non-consensus node; receives the query result corresponding to the query request fed back by the second target non-consensus node, and sends the query result to the client.

[0110] Exemplarily, as Figure 3 shown, if the client requests to query block2, the checkpoint block in the same segment as block2 is block3. The second non-consensus node determines the target checkpoint block block3 corresponding to block2, calculates the target distance value between the second non-consensus node and block3 according to the node ID of the second non-consensus node and the hash value corresponding to block3; determines the second target non-consensus node corresponding to block3 according to the target distance value and the node routing table; the second non-consensus node forwards the query request to the second target non-consensus node, receives the query result corresponding to the query request fed back by the second target non-consensus node, and sends the query result to the client.

[0111] In this embodiment, if the second non-consensus node has the target block to be queried by the client, the second non-consensus node is the second target non-consensus node, and the query request is processed locally at the second non-consensus node; if the second non-consensus node does not have the target block to be queried by the client, the query request is forwarded to the second target non-consensus node corresponding to the target block for processing.

[0112] Step S503: The second non-consensus node sends the query result obtained by the second target non-consensus node processing the query request to the client.

[0113] In the embodiment of the present application, the query request of the client may be processed locally by the second non-consensus node, and then the second non-consensus node sends the query result to the client, or may be processed by other non-consensus nodes in the non-consensus node cluster and fed back to the second non-consensus node, and then the second non-consensus node conveys it to the client.

[0114] Exemplarily, taking an application scenario as an example, as Figure 6As shown in the figure, the consensus node VP is connected to NVP1 in the NVP cluster, and the client is connected to NVP4 in the NVP cluster. NVP1 synchronizes blocks 0 to 100 from VP. According to the distributed hash algorithm and the node routing table corresponding to the NVP cluster, blocks 0 to 100 are distributed and stored in NVP1 to NVP4. NVP1 stores blocks 0 to 25, NVP2 stores blocks 26 to 50, NVP3 stores blocks 51 to 75, and NVP4 stores blocks 75 to 100. NVP1 to NVP4 all store the block headers of blocks 0 to 100. When the client requests to query block 45, NVP4 can determine through local query that there is block 45 in this NVP cluster, but NVP4 does not locally store block 45. At this time, NVP4 can determine based on the node routing table that block 45 is stored in NVP2. NVP4 forwards the client's query request to NVP2, NVP2 processes the query request, and NVP4 then sends the query result feedback by NVP2 to the client.

[0115] It can be seen that in the embodiments of the present application, each non-consensus node in the non-consensus node cluster stores the block headers of all blocks, and the block bodies of the blocks are distributed and stored in the first target non-consensus nodes corresponding to each block according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, which can effectively reduce the storage pressure of a single non-consensus node, thereby reducing the storage cost of the entire system. At the same time, since each non-consensus node stores the block headers of all blocks, it helps the client to send a query request to any non-consensus node in the non-consensus node cluster. The non-consensus node cluster can process the query request, and the client does not need to send a query request to the consensus node, which can effectively reduce the query pressure on the consensus node, and thus improve the performance and reliability of the system.

[0116] It should be understood that the magnitudes of the sequence numbers of the steps in the above various embodiments do not mean the order of execution. The order of execution of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0117] Corresponding to the block storage method based on distributed hash described in the above embodiments, Figure 7.1 The structural block diagram of the block storage device based on distributed hash provided by the embodiments of the present application is shown. For the sake of convenience of description, only the parts related to the embodiments of the present application are shown.

[0118] Refer to Figure 7.1 , the block storage device based on distributed hash is applied to a blockchain platform. The block storage device includes: a block synchronization unit 71 and a block storage unit 72, where:

[0119] The block synchronization unit 71 is used for the first non-consensus node in the non-consensus node cluster to synchronize the to-be-stored blocks in the block list from the consensus node, and synchronously store the block headers of the to-be-stored blocks into all non-consensus nodes in the non-consensus node cluster. The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node;

[0120] The block storage unit 72 is used for the first non-consensus node to determine the first target non-consensus nodes corresponding to the to-be-stored blocks in the block list according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, and store the block bodies of the to-be-stored blocks into the first target non-consensus nodes corresponding to the to-be-stored blocks.

[0121] As a possible implementation manner of the present application, the above block storage unit 72 is further used for:

[0122] When the to-be-stored block synchronized by the first non-consensus node is a checkpoint block, the first non-consensus node calculates the distance value between the first non-consensus node and the checkpoint block according to the node ID of the first non-consensus node and the hash value corresponding to the checkpoint block;

[0123] The first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks according to the distance value and the node routing table. The same-segment blocks refer to the to-be-stored blocks between the checkpoint block and its previous checkpoint block in the block list. The first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks are the same;

[0124] The above storing the block bodies of the to-be-stored blocks into the first target non-consensus nodes corresponding to the to-be-stored blocks includes:

[0125] Packing and storing the block bodies of the checkpoint block and its same-segment blocks in the block list together into the first target non-consensus node.

[0126] As a possible implementation manner of the present application, the node routing table includes the node information of several bucket non-consensus nodes and the distance interval corresponding to each bucket;

[0127] The above first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks according to the distance value and the node routing table, including:

[0128] The first non-consensus node determines the distance interval to which the distance value belongs in the node routing table;

[0129] The first non-consensus node determines the first target non-consensus node corresponding to the inspection node block and its same-segment blocks according to the node information of the non-consensus nodes in the bucket corresponding to the distance interval to which it belongs.

[0130] As a possible implementation manner of the present application, referring to Figure 7.2 , the above-mentioned block storage device further includes: a query request receiving unit 73, a query request processing unit 74, and a query result sending unit 75, where:

[0131] The query request receiving unit 73 is used for the second non-consensus node in the non-consensus node cluster to receive a query request sent by a client, and the second non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the client;

[0132] The query request processing unit 74 is used for the second non-consensus node to determine the second target non-consensus node corresponding to the query request based on the node routing table, and instruct the second target non-consensus node to process the query request;

[0133] The query result sending unit 75 is used for the second non-consensus node to send the query result obtained by the second target non-consensus node processing the query request to the client.

[0134] As a possible implementation manner of the present application, the above-mentioned query request carries a query type and a target block header of a target block; the second non-consensus node determines the second target non-consensus node corresponding to the query request based on the node routing table, and instructs the second target non-consensus node to process the query request, including:

[0135] The second non-consensus node determines whether the target block header exists in the non-consensus node cluster;

[0136] If the target block header exists in the non-consensus node cluster, the second non-consensus node is the second target consensus node, and the second non-consensus node determines whether the target block body corresponding to the target block header exists locally in the second non-consensus node;

[0137] If the target block body exists locally in the second non-consensus node, the second non-consensus node determines a target query result according to the query type and the target block body, and feeds back the target query result to the client.

[0138] As a possible implementation manner of the present application, the second non-consensus node determining the second target non-consensus node corresponding to the query request based on the node routing table and instructing the second target non-consensus node to process the query request further includes:

[0139] If the target block body does not exist locally in the second non-consensus node, the second non-consensus node determines a target checkpoint block corresponding to the target block, and the target checkpoint block is a block in the same segment as the target block.

[0140] The second non-consensus node calculates a target distance value between the second non-consensus node and the target checkpoint block according to the node ID of the second non-consensus node and the hash value corresponding to the target checkpoint block.

[0141] The second non-consensus node determines a second target non-consensus node corresponding to the target checkpoint block according to the target distance value and the node routing table.

[0142] The second non-consensus node forwards the query request to the second target non-consensus node.

[0143] Receive the query result corresponding to the query request fed back by the second target non-consensus node, and send the query result to the client.

[0144] As a possible implementation manner of the present application, the above block storage device further includes a node routing table construction unit, which is used for:

[0145] The non-consensus node cluster calculates the node distance values between the non-consensus nodes in the non-consensus node cluster according to the node IDs of the non-consensus nodes in the non-consensus node cluster.

[0146] The non-consensus node cluster performs hierarchical processing on the non-consensus nodes in the non-consensus node cluster based on the node distance values, and determines a number of buckets according to the hierarchical processing result, and each bucket contains non-consensus nodes within a distance interval.

[0147] The non-consensus node cluster constructs a node routing table corresponding to the non-consensus node cluster based on the number of buckets.

[0148] As can be seen from the above, in the embodiments of the present application, each non-consensus node in the non-consensus node cluster stores the block headers of all blocks, and the block bodies of the blocks are distributedly stored in the first target non-consensus nodes corresponding to each block according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, which can effectively reduce the storage pressure of a single non-consensus node, thereby reducing the storage cost of the entire system. At the same time, since each non-consensus node stores the block headers of all blocks, it helps the client to send a query request to any non-consensus node in the consensus node cluster, and the non-consensus node cluster can process the query request. The client does not need to send a query request to the consensus node, which can effectively reduce the query pressure of the consensus node, and thus can improve the performance and reliability of the system.

[0149] The embodiments of the present application further provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any one of the block storage methods based on distributed hash as shown in Figures 2 to 6 are implemented.

[0150] The embodiments of the present application further provide a computer program product. When the computer program product runs on a terminal device, the terminal device is enabled to execute the steps of any one of the block storage methods based on distributed hash as shown in Figures 2 to 6 are implemented.

[0151] The embodiments of the present application further provide a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of any one of the vehicle driving environment anomaly monitoring methods as shown in Figures 2 to 6 are implemented.

[0152] Figure 8 is a schematic diagram of a server provided by an embodiment of the present application. As shown in Figure 8 , the server 8 of this embodiment includes: a processor 80, a memory 81, and a computer program 82 stored in the memory 81 and executable on the processor 80. When the processor 80 executes the computer program 82, the steps in the above-mentioned embodiments of each block storage method based on distributed hash are implemented, such as Figure 2 the steps S201 to S202 shown in Figure 5 the steps S501 to S503 shown in Figure 7.1 Or, when the processor 80 executes the computer program 82, the functions of each module / unit in the above-mentioned device embodiments are implemented, such as Figure 7.2 the functions of the units 71 to 72 shown in

[0153] The computer program 82 can be divided into one or more modules / units. The one or more modules / units are stored in the memory 81 and executed by the processor 80 to complete the present application. The one or more modules / units can be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program 82 in the server 8.

[0154] The so-called processor 80 may be a Central Processing Unit (CPU), or may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0155] The memory 81 may be an internal storage unit of the server 8, such as the hard disk or memory of the server 8. The memory 81 may also be an external storage device of the server 8, such as a plug-in hard disk equipped on the server 8, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Further, the memory 81 may also include both the internal storage unit of the server 8 and the external storage device. The memory 81 is used to store the computer program and other programs and data required by the server. The memory 81 may also be used to temporarily store data that has been output or is to be output.

[0156] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules as needed, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment may be integrated in a processing unit, or each unit may exist physically alone, or two or more units may be integrated in one unit. The above integrated unit may be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of this application. The specific working processes of the units and modules in the above system can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated here.

[0157] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, device, and unit can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated here.

[0158] In the above embodiments, the descriptions of the respective embodiments have their own emphases. For parts not described or recorded in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0159] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0160] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the couplings or direct couplings or communication connections shown or discussed with each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

[0161] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they can be located in one place, or can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0162] In addition, the functional units in the various embodiments of this application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0163] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-mentioned embodiment methods of this application, it can also be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0164] The above-described embodiments are only used to illustrate the technical solutions of this application, rather than to limit them; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A block storage method based on distributed hash, characterized in that, Applied to a non-consensus node cluster, the method includes: The first non-consensus node in the non-consensus node cluster synchronizes the to-be-stored blocks in the block list from the consensus node, and synchronously stores the block headers of the to-be-stored blocks in all non-consensus nodes within the non-consensus node cluster. The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node; The first non-consensus node determines the first target non-consensus nodes corresponding to the to-be-stored blocks in the block list according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, including: When the to-be-stored block synchronized by the first non-consensus node is a checkpoint block, the first non-consensus node calculates the distance value between the first non-consensus node and the checkpoint block according to the node ID of the first non-consensus node and the hash value corresponding to the checkpoint block; the first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks according to the distance value and the node routing table. The same-segment blocks refer to the to-be-stored blocks between the checkpoint block and its previous checkpoint block in the block list. The first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks are the same. The node routing table includes the node information of several bucket non-consensus nodes and the distance interval corresponding to each bucket; The first non-consensus node packs and stores the block bodies of the checkpoint block and its same-segment blocks in the block list together in the first target non-consensus node.

2. The method according to claim 1, wherein The first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks according to the distance value and the node routing table, including: The first non-consensus node determines the distance interval to which the distance value belongs in the node routing table; The first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks according to the node information of the non-consensus nodes in the bucket corresponding to the belonging distance interval.

3. The method according to claim 1, wherein The method further includes: The second non-consensus node in the non-consensus node cluster receives a query request sent by the client. The second non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the client; The second non-consensus node determines the second target non-consensus node corresponding to the query request based on the node routing table, and instructs the second target non-consensus node to process the query request; The second non-consensus node sends the query result obtained by the second target non-consensus node processing the query request to the client.

4. The method according to claim 3, wherein The query request carries a query type and the target block header of the target block. The second non-consensus node determines the second target non-consensus node corresponding to the query request based on the node routing table, and instructs the second target non-consensus node to process the query request, including The second non-consensus node determines whether the target block header exists in the non-consensus node cluster; If the target block header exists in the non-consensus node cluster, the second non-consensus node is the second target consensus node, and the second non-consensus node determines whether the target block body corresponding to the target block header exists locally in the second non-consensus node; If the target block body exists locally in the second non-consensus node, the second non-consensus node determines a target query result according to the query type and the target block body, and feeds back the target query result to the client.

5. The method according to claim 4, wherein The second non-consensus node determines a second target non-consensus node corresponding to the query request according to the node routing table, and instructs the second target non-consensus node to process the query request, including: If the target block body does not exist locally in the second non-consensus node, the second non-consensus node determines a target checkpoint block corresponding to the target block, and the target checkpoint block is a block in the same segment as the target block; The second non-consensus node calculates a target distance value between the second non-consensus node and the target checkpoint block according to the node ID of the second non-consensus node and the hash value corresponding to the target checkpoint block; The second non-consensus node determines a second target non-consensus node corresponding to the target checkpoint block according to the target distance value and the node routing table; The second non-consensus node forwards the query request to the second target non-consensus node; Receives the query result corresponding to the query request fed back by the second target non-consensus node, and sends the query result to the client.

6. The method according to any one of claims 1 to 5, characterized in that Before the first non-consensus node determines a first target non-consensus node corresponding to each block to be stored in the block list according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, it further includes: The non-consensus node cluster calculates node distance values between non-consensus nodes in the non-consensus node cluster according to the node IDs of non-consensus nodes in the non-consensus node cluster; The non-consensus node cluster performs hierarchical processing on non-consensus nodes in the non-consensus node cluster based on the node distance values, and determines a number of buckets according to the hierarchical processing result, and each bucket contains non-consensus nodes within a distance interval; The non-consensus node cluster constructs a node routing table corresponding to the non-consensus node cluster based on the number of buckets; 7. A block storage system based on distributed hashing, characterized in that, The system includes a consensus node and a non-consensus node cluster. The non-consensus node cluster includes a first non-consensus node, and the first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node; wherein: The consensus node is used to synchronize blocks to be stored in the block list with the first non-consensus node; The first non-consensus node is used to synchronize the to-be-stored blocks in the block list from the consensus node, and synchronously store the block headers of the to-be-stored blocks into all non-consensus nodes in the non-consensus node cluster. The first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node. According to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, determining the first target non-consensus nodes corresponding to the to-be-stored blocks in the block list includes: when the to-be-stored block synchronized by the first non-consensus node is a checkpoint block, the first non-consensus node calculates the distance value between the first non-consensus node and the checkpoint block according to the node ID of the first non-consensus node and the hash value corresponding to the checkpoint block; the first non-consensus node determines the first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks according to the distance value and the node routing table. The same-segment blocks refer to the to-be-stored blocks between the checkpoint block and its previous checkpoint block in the block list. The first target non-consensus nodes corresponding to the checkpoint block and its same-segment blocks are the same. The node routing table includes the node information of several bucket non-consensus nodes and the distance interval corresponding to each bucket; the block bodies of the checkpoint block and its same-segment blocks in the block list are packaged and stored together in the first target non-consensus node.

8. A server, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the block storage method based on distributed hash as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the block storage method based on distributed hash as described in any one of claims 1 to 6.

Images