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

Abstract

The invention relates to the technical field of block chains, in particular to a distributed hash-based block storage method, system and device and a server, the method is applied to a non-consensus node cluster, and the method comprises the following steps: a first non-consensus node in the non-consensus node cluster synchronizes a to-be-stored block in a block list from a consensus node, synchronously storing a block head of the to-be-stored block into all non-consensus nodes in a non-consensus node cluster, wherein a first non-consensus node is any one non-consensus node connected with the consensus node in the non-consensus node cluster; and the first non-consensus node determines a first target non-consensus node corresponding to each to-be-stored block in the block list according to a distributed hash algorithm and a node routing table corresponding to the non-consensus node cluster, and stores the block body of each to-be-stored block to the first target non-consensus node corresponding to each to-be-stored block. By adopting the method, the query pressure of the VP and the storage pressure of the NVP can be effectively reduced, and the overall storage cost of the system is reduced.

Description

Technical Field

[0001] The present 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] Blockchain is a distributed system based on a P2P network. All nodes jointly maintain the blockchain network without a centralized control organization. Due to the characteristics of decentralization and immutability of blockchain, blockchain technology has developed rapidly and is widely used in various fields. In the blockchain architecture of the alliance chain, when deploying consensus nodes (Validating Peer, VP), some non-consensus nodes (None-Validating Peer, NVP) are usually deployed to reduce the query burden of consensus nodes and optimize performance. VP needs to participate in the block consensus process, while NVP does not need to participate in the block consensus process. However, in order to maintain the consistency of data in the blockchain nodes, these NVPs do not participate in the consensus process, but need to synchronize and store all block data of VP to provide query services to the outside world.

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

[0004] In view of this, how to effectively reduce the query pressure of VP and the storage pressure of NVP and reduce the overall storage cost of the system is an urgent problem that needs to be solved. Summary of the invention

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

[0006] A first aspect of an embodiment of the present application provides a block storage method based on distributed hashing, which is applied to a non-consensus node cluster. The method includes: The first non-consensus node in the non-consensus node cluster synchronizes the block to be stored in the block list from the consensus node, and synchronously stores the block header of the block to be stored in all non-consensus nodes in the non-consensus node cluster, wherein 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 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 stores the block body of each block to be stored to the first target non-consensus node corresponding to each block to be stored.

[0007] In a possible implementation manner of the first aspect, the first non-consensus node determines, according to a distributed hash algorithm and a node routing table corresponding to the non-consensus node cluster, a first target non-consensus node corresponding to each to-be-stored block in the block list, including: 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; The first non-consensus node determines, according to the distance value and the node routing table, a first target non-consensus node corresponding to the checkpoint block and the same-segment block thereof, wherein the same-segment block refers to a block to be stored between the checkpoint block and the previous checkpoint block in the block list, and the first target non-consensus node corresponding to the checkpoint block and the same-segment block thereof is the same; 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 includes: The checkpoint block and the block bodies of the blocks in the same segment in the block list are packaged together and stored in the first target non-consensus node.

[0008] In a possible implementation manner of the first aspect, 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, according to the distance value and the node routing table, a first target non-consensus node corresponding to the checkpoint block and the block in the same segment, including: The first non-consensus node determines a 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 the block in the same segment according to the node information of the non-consensus nodes in the bucket corresponding to the distance interval.

[0009] In a possible implementation manner of the first aspect, the method further includes: A second non-consensus node in the non-consensus node cluster receives a query request sent by the client, where the second non-consensus node is any non-consensus node in the non-consensus node cluster connected to the client; The second non-consensus node determines, based on the node routing table, a second target non-consensus node corresponding to the query request, 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.

[0010] 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; the second non-consensus node determines, based on the node routing table, 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: 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 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 the target query result back to the client.

[0011] In a possible implementation manner of the first aspect, the second non-consensus node determines, according to the node routing table, a second target non-consensus node corresponding to the query request, and instructs the second target non-consensus node to process the query request, further comprising: 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, where 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 a hash value corresponding to the node ID of the second non-consensus node and the target checkpoint block; The second non-consensus node determines, according to the target distance value and the node routing table, a second target non-consensus node corresponding to the target checkpoint block; The second non-consensus node forwards the query request to the second target non-consensus node; 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.

[0012] In a possible implementation manner of the first aspect, before the first non-consensus node determines, according to a distributed hash algorithm and a node routing table corresponding to the non-consensus node cluster, a first target non-consensus node corresponding to each to-be-stored block in the block list, further comprising: 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; The non-consensus node cluster performs a hierarchical process on the non-consensus nodes in the non-consensus node cluster based on the node distance value, and determines a plurality of buckets according to the hierarchical process result, each bucket containing 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 plurality of buckets.

[0013] In an embodiment 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 to 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, 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 is helpful for the client to make 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 of the consensus node, thereby improving the performance and reliability of the system.

[0014] A second aspect of an embodiment of the present application provides a block storage system based on distributed hashing, the system comprising a consensus node and a non-consensus node cluster, the non-consensus node cluster comprising a first non-consensus node, the first non-consensus node being any non-consensus node in the non-consensus node cluster connected to the consensus node; wherein: The consensus node is used to synchronize the blocks to be stored in the block list with the first non-consensus node; 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, where the first non-consensus node is any non-consensus node in the non-consensus node cluster connected to the consensus node; 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 body of each block to be stored in the first target non-consensus node corresponding to each block to be stored.

[0015] A third aspect of an embodiment of the present application provides a block storage device based on distributed hashing, which is applied to a non-consensus node cluster, and the device includes: A block synchronization unit, configured for a first non-consensus node in the non-consensus node cluster to synchronize a block to be stored in a block list from a consensus node, and to synchronously store a block header of the block to be stored in all non-consensus nodes in the non-consensus node cluster, wherein the first non-consensus node is any non-consensus node in the non-consensus node cluster connected to the consensus node; The block storage unit is used for 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 body of each block to be stored to the first target non-consensus node corresponding to each block to be stored.

[0016] A fourth aspect of an embodiment of the present application provides a server, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein when the processor executes the computer program, the steps of the distributed hash-based block storage method provided in the first aspect of the embodiment of the present application are implemented.

[0017] A fifth aspect of an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of the distributed hash-based block storage method provided in the first aspect of the embodiment of the present application.

[0018] 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 executes the steps of the distributed hash-based block storage method described in the first aspect of the embodiments of the present application.

[0019] It can be understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0021] Figure 1.1 This is a system architecture diagram of a distributed hash-based block storage system provided in an embodiment of the present application; Figure 1.2 This is another system architecture diagram of a distributed hash-based block storage system provided in an embodiment of the present application; Figure 2 It is a flowchart of an implementation method of a block storage method based on distributed hashing provided in an embodiment of the present application; Figure 3 It is a schematic diagram of block segmentation in a block storage method based on distributed hashing provided in an embodiment of the present application; Figure 4.1 It is a specific implementation flow chart 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; Figure 4.2 It is a schematic diagram of a node routing table in a block storage method based on distributed hashing provided in an embodiment of the present application; Figure 5 This is a schematic diagram of an application scenario of a block query method based on distributed hashing provided in an embodiment of the present application; Figure 6 This is a schematic diagram of an application scenario of a block storage method based on distributed hashing provided in an embodiment of the present application; Figure 7.1 It is a structural block diagram of a distributed hash-based block storage device provided in an embodiment of the present application; Figure 7.2 is another structural block diagram of a distributed hash-based block storage device provided in an embodiment of the present application; Figure 8 A schematic diagram of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may 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 prevent unnecessary details from obstructing the description of the present application.

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

[0024] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some 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 "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0025] In some blockchain networks, consensus nodes and non-consensus nodes are deployed at the same time. Consensus nodes are responsible for the creation and verification of blocks, maintaining the security and consistency of the entire blockchain; non-consensus nodes are mainly used for data query and storage, and assist in improving the overall performance of the network. Currently, there are two main types of data storage solutions for non-consensus nodes in blockchains. The first solution is to fully synchronize the block data of consensus nodes. Non-consensus nodes fully synchronize all block data from consensus nodes, including transaction details. The second solution is that non-consensus nodes only synchronize block header information, without specific transaction details. For the first solution, each non-consensus node needs to store complete blockchain data, which requires a high storage capacity for a single node. Moreover, if multiple non-consensus nodes fully synchronize complete block data, there will be a large amount of data redundancy in the network, and the system redundant storage cost is high. For the second solution, although the storage pressure of non-consensus nodes is reduced, when transaction details need to be queried, non-consensus nodes still need to send requests to consensus nodes, which does not really reduce the query pressure of consensus nodes and may also reduce the overall performance of the network.

[0026] In response to the above problems, 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 the block headers of the blocks to be stored are synchronously stored in all non-consensus nodes in the non-consensus node cluster. At the same time, according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, the first target non-consensus node corresponding to each block to be stored in the block list is determined, and the block body of each block to be stored is stored in the first target non-consensus node corresponding to each block to be stored. The adoption of the solution of the present application can realize distributed storage of blocks, without the need for each non-consensus node to fully synchronize block data, effectively reducing the storage pressure of a single non-consensus node cluster in the system, 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 is helpful for the client to make 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.

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

[0028] In order to illustrate the technical solution described in this application, a specific embodiment is provided below for illustration.

[0029] Figure 1.1 A system architecture diagram of a distributed hash-based block storage system provided in an embodiment of the present application is shown, which is described in detail as follows: For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0030] Reference Figure 1.1 , the distributed hash-based block storage system 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, the plurality of non-consensus nodes include a first non-consensus node 2-1, the first non-consensus node 2-1 is any non-consensus node in the non-consensus node cluster 2 connected to the consensus node 1; wherein: The first non-consensus node 2-1 synchronizes the block to be stored in the block list from the consensus node 1, and stores the block header of the block to be stored in all non-consensus nodes in the non-consensus node cluster 2.

[0031] The first non-consensus node 2-1 determines 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 2, and stores the block body of each block to be stored to the first target non-consensus node corresponding to each block to be stored.

[0032] As a possible implementation of the present application, Figure 1.2 As shown, the distributed hash-based block storage system also includes a client 3, and 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 connected to the client 3; wherein: The client is used to send a query request to the second non-consensus node; 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, and instruct the second target non-consensus node to process the query request; and send the query result to the client.

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

[0034] As the scale of the alliance chain network expands, deploying multiple non-consensus nodes can effectively expand query capabilities and support more users to query blockchain data at the same time. By building a 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-public nodes in the non-consensus node cluster 2 to connect and communicate with the consensus node 1, and other non-public nodes in the non-consensus node cluster 2 are all connected to the first non-consensus node 2-1.

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

[0036] On the other hand, the first non-consensus node 2-1 determines 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 distributes the block body of each block to be stored to the first target non-consensus node corresponding to each block to be stored, thereby realizing distributed allocation of block bodies. There is no need for all non-consensus nodes in the non-consensus node cluster 2 to synchronously store all block bodies, which effectively reduces the storage pressure of a single non-consensus node, and thus reduces the storage cost of the entire system.

[0037] In one possible implementation, 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 .

[0038] In a possible implementation, 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 non-consensus nodes 1 through multiple first non-consensus nodes 2-1.

[0039] Exemplarily, VP1 is connected to NVP1 in the NVP cluster, NVP1 synchronizes the blocks to be stored in the VP1 block list, and synchronously stores the block headers of the blocks to be stored in the VP1 block list in all NVPs in the NVP cluster, and NVP determines the storage node (non-consensus node in the NVP cluster) 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 NVP cluster, and stores the block body of the block to be stored in the VP1 block list to the storage node. VP2 is connected to NVP2 in the NVP cluster, and NVP2 synchronizes the blocks to be stored in the VP2 block list, and synchronously stores the block headers of the blocks to be stored in the VP2 block list in all NVPs in the NVP cluster, and NVP determines the storage node (non-consensus node in the NVP cluster) 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 NVP cluster, and stores the block body of the block to be stored in the VP2 block list to the storage node. NVP1 and NVP2 are both the first non-consensus nodes in this embodiment.

[0040] In an embodiment 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 to 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, 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 is helpful for the client to make 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 of the consensus node, thereby improving the performance and reliability of the system.

[0041] Figure 2 The implementation process of the block storage method based on distributed hashing provided by the embodiment of the present application is shown. The embodiment of the present application is applied to a non-consensus node cluster. The method flow may include the following steps S201 to S202. The specific implementation principle of each step is as follows: Step S201: The first non-consensus node in the non-consensus node cluster synchronizes the block to be stored in the block list from the consensus node, and synchronously stores the block header of the block to be stored in all non-consensus nodes in the non-consensus node cluster.

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

[0043] When the consensus nodes verify a set of transactions and reach a consensus, they will package these transactions into a new block and broadcast it to other nodes in the entire network. This new block contains all 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.

[0044] The above-mentioned block to be stored is the new block after verification by the first non-consensus node. In the embodiment of the present application, the first non-consensus node will verify the new block after receiving it from the consensus node. If the verification is successful, the first non-consensus node will add the block header of the new block to its local account book, and at the same time, the block header of the new block will be synchronously sent to other non-consensus nodes in the non-consensus node cluster for storage. This process ensures that each non-consensus node in the non-consensus node cluster stores the block header of the new block.

[0045] Step S202: The first non-consensus node determines 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 stores the block body of each block to be stored to the first target non-consensus node corresponding to each block to be stored.

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

[0047] 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 alliance chain network. The embodiment of the present application is based on the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster. The block body of the block to be stored synchronized from the consensus node is distributedly stored to the first target non-consensus node corresponding to each block to be stored, which can effectively reduce the storage pressure of a single non-consensus node in the non-consensus node cluster and effectively reduce the storage cost of the entire system.

[0048] As a possible implementation mode of the present application, 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. The first non-consensus node determines the first target non-consensus node corresponding to the checkpoint block and its same-segment block according to the distance value and the node routing table. The same-segment block refers to the block to be stored between the checkpoint block and the previous checkpoint block in the block list, and the first target non-consensus node corresponding to the checkpoint block and its same-segment block is the same. The block bodies of the checkpoint block and its same-segment block in the block list are packaged together and stored in the first target non-consensus node.

[0049] 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 packaged together and 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.

[0050] For example, take an application scenario as an example. 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.

[0051] 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.

[0052] 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.

[0053] 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: 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.

[0054] 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.

[0055] A2: The non-consensus node cluster performs stratification processing on the non-consensus nodes in the non-consensus node cluster based on the node distance value, and determines a number of buckets according to the stratification processing result, each bucket containing non-consensus nodes within a distance interval. Each bucket corresponds to a distance interval.

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

[0057] In this embodiment, the above-mentioned 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 the node routing table constructed based on the Kademlia algorithm, the search range can be shrunk like folding a piece of paper in half, ensuring that for any n non-consensus nodes, only log2(n) queries are needed at most to find the target non-consensus node, which can effectively improve the efficiency of storage and query.

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

[0059] For example, Figure 4.2 A routing table is shown, which takes node 6 as the main perspective and shows the XOR distances between other NVPs and node 6. Figure 4.2 There are 3 buckets in , where K is 2, which means that there are no more than 2 non-consensus nodes in each bucket. Figure 4.2 In the figure, the XOR distance between NVP(7) and NVP(6) is 1 (110XOR110), the XOR distance between NVP(4) and NVP(6) is 2 (100XOR110), the XOR distance between NVP(5) and NVP(6) is 3 (101XOR110), the XOR distance between NVP(0) and NVP(6) is 6 (000XOR110), the XOR distance between NVP(1) and NVP(6) is 7 (001XOR110), the XOR distance between NVP(2) and NVP(6) is 4 (010XOR110), and the XOR distance between NVP(3) and NVP(6) is 5 (011XOR110). For the third bucket, the number of nodes exceeds the K value, and the two excess nodes NVP(2) and NVP(3) are used as candidate nodes.

[0060] As a possible implementation of this application, Figure 5The implementation process of the block query method based on distributed hashing provided by the embodiment of the present application is shown. The embodiment of the present application is applied to a non-consensus node cluster. The method flow may include the following steps S501 to S503. The specific implementation principle of each step is as follows: Step S501: A second non-consensus node in the non-consensus node cluster receives a query request sent by a client.

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

[0062] 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.

[0063] The query request carries the query type and the 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.

[0064] 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 the target query result according to the query type and the target block body, and feeds the target query result back to the client.

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

[0066] As a possible implementation mode of the present application, if the target block body does not exist locally on the second non-consensus node, the second non-consensus node determines the target checkpoint block corresponding to the target block, and the target checkpoint block is the same segment block of the target block; the second non-consensus node calculates the target distance value between the second non-consensus node and the target checkpoint block based on 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 the second target non-consensus node corresponding to the target checkpoint block based on 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.

[0067] For example, Figure 3 As shown, if the client requests to query block2, and the checkpoint block in the same segment of block2 is block3, the second non-consensus node determines the target checkpoint block block3 corresponding to block2, and 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.

[0068] In this embodiment, if the second non-consensus node has a target block that the client wants to query, 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 a target block that the client wants to query, the query request is forwarded to the second target non-consensus node corresponding to the target block for processing.

[0069] 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.

[0070] In an embodiment of the present application, the query request of the client may be processed locally by the second non-consensus node, and the query result may be sent to the client by the second non-consensus node. It may also be processed by other non-consensus nodes in the non-consensus node cluster and then fed back to the second non-consensus node, which then conveys it to the client.

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

[0072] It can be seen that in the embodiment 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 to 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, 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 is helpful for the client to make 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 of the consensus node, thereby improving the performance and reliability of the system.

[0073] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0074] Corresponding to the block storage method based on distributed hashing described in the above embodiment, Figure 7.1 A structural block diagram of a distributed hash-based block storage device provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0075] Reference Figure 7.1 The block storage device based on distributed hashing is applied to the blockchain platform. The block storage device includes: a block synchronization unit 71 and a block storage unit 72, wherein: A block synchronization unit 71 is used for a first non-consensus node in the non-consensus node cluster to synchronize a block to be stored in a block list from a consensus node, and to synchronize and store a block header of the block to be stored in all non-consensus nodes in the non-consensus node cluster, wherein the first non-consensus node is any non-consensus node in the non-consensus node cluster that is connected to the consensus node; The block storage unit 72 is used for 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 body of each block to be stored to the first target non-consensus node corresponding to each block to be stored.

[0076] As a possible implementation of the present application, the block storage unit 72 is further used for: 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; The first non-consensus node determines, according to the distance value and the node routing table, a first target non-consensus node corresponding to the checkpoint block and the same-segment block thereof, wherein the same-segment block refers to a block to be stored between the checkpoint block and the previous checkpoint block in the block list, and the first target non-consensus node corresponding to the checkpoint block and the same-segment block thereof is the same; The above-mentioned storing the block bodies of each block to be stored in the first target non-consensus node corresponding to each block to be stored includes: The checkpoint block and the block bodies of the blocks in the same segment in the block list are packaged together and stored in the first target non-consensus node.

[0077] As a possible implementation of the present application, 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 first target non-consensus node corresponding to the checkpoint block and the same segment block according to the distance value and the node routing table, including: The first non-consensus node determines a 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 the block in the same segment according to the node information of the non-consensus nodes in the bucket corresponding to the distance interval.

[0078] As a possible implementation of this application, refer to Figure 7.2The block storage device further includes: a query request receiving unit 73, a query request processing unit 74, and a query result sending unit 75, wherein: A query request receiving unit 73, configured for a second non-consensus node in the non-consensus node cluster to receive a query request sent by a client, wherein the second non-consensus node is any non-consensus node in the non-consensus node cluster connected to the client; A query request processing unit 74, configured for the second non-consensus node to determine a second target non-consensus node corresponding to the query request based on the node routing table, and to instruct the second target non-consensus node to process the query request; 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.

[0079] As a possible implementation manner of the present application, the query request carries the 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 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 the target query result back to the client.

[0080] As a possible implementation manner of the present application, the second non-consensus node determines the 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 comprising: 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, where 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 a hash value corresponding to the node ID of the second non-consensus node and the target checkpoint block; The second non-consensus node determines, according to the target distance value and the node routing table, a second target non-consensus node corresponding to the target checkpoint block; The second non-consensus node forwards the query request to the second target non-consensus node; 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.

[0081] As a possible implementation manner of the present application, the block storage device further includes a node routing table construction unit, which is used to: 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; The non-consensus node cluster performs a hierarchical process on the non-consensus nodes in the non-consensus node cluster based on the node distance value, and determines a plurality of buckets according to the hierarchical process result, each bucket containing 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 plurality of buckets.

[0082] As can be seen from the above, in the embodiment 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 to 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, 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 is helpful for the client to make a query request to any non-consensus node in the 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 of the consensus node, thereby improving the performance and reliability of the system.

[0083] The present application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, Figures 2 to 6 The steps of any distributed hash-based block storage method are represented.

[0084] The embodiment of the present application also provides a computer program product, when the computer program product is run on a terminal device, the terminal device executes the following Figures 2 to 6 The steps of any distributed hash-based block storage method are represented.

[0085] The embodiment of the present application also provides a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, Figures 2 to 6 The steps of any one of the vehicle driving environment abnormality monitoring methods are represented.

[0086] Figure 8 Schematic diagram of a server provided by an embodiment of the present application. Figure 8 As shown, 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 the block storage method based on distributed hashing are implemented, for example Figure 2 Steps S201 to S202 shown in FIG. Figure 5 Alternatively, when the processor 80 executes the computer program 82, the functions of each module / unit in the above-mentioned device embodiments are realized, for example Figure 7.1 The functions of the units 71 to 72 shown, Figure 7.2 The functions of units 73 to 75 are shown.

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

[0088] The processor 80 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0089] The memory 81 may be an internal storage unit of the server 8, such as a 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, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the server 8. Further, the memory 81 may include both an internal storage unit of the server 8 and an 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.

[0090] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0091] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0092] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0093] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0094] In the embodiments provided in the present 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 only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0095] 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 may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0096] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0097] 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, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained 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, computer-readable media do not include electric carrier signals and telecommunication signals.

[0098] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A block storage method based on distributed hashing, 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 block to be stored in the block list from the consensus node, and synchronously stores the block header of the block to be stored in all non-consensus nodes in the non-consensus node cluster, wherein 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 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 stores the block body of each block to be stored to the first target non-consensus node corresponding to each block to be stored.

2. The method according to claim 1, characterized in that The first non-consensus node determines the first target non-consensus node corresponding to each to-be-stored block 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 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; The first non-consensus node determines, according to the distance value and the node routing table, a first target non-consensus node corresponding to the checkpoint block and the same-segment block thereof, wherein the same-segment block refers to a block to be stored between the checkpoint block and the previous checkpoint block in the block list, and the first target non-consensus node corresponding to the checkpoint block and the same-segment block thereof is the same; 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 includes: The checkpoint block and the block bodies of the blocks in the same segment in the block list are packaged together and stored in the first target non-consensus node.

3. The method according to claim 2, characterized in that The node routing table includes node information of several bucket non-consensus nodes and the distance interval corresponding to each bucket; The first non-consensus node determines, according to the distance value and the node routing table, a first target non-consensus node corresponding to the checkpoint block and the block in the same segment, including: The first non-consensus node determines a 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 the block in the same segment according to the node information of the non-consensus nodes in the bucket corresponding to the distance interval.

4. The method according to claim 1, characterized in that The method further comprises: A second non-consensus node in the non-consensus node cluster receives a query request sent by the client, where the second non-consensus node is any non-consensus node in the non-consensus node cluster connected to the client; The second non-consensus node determines, based on the node routing table, a second target non-consensus node corresponding to the query request, 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.

5. The method according to claim 4, characterized in that The query request carries the 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 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 the target query result back to the client.

6. The method according to claim 5, characterized in that The second non-consensus node determines, according to the node routing table, 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: 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, where 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 a hash value corresponding to the node ID of the second non-consensus node and the target checkpoint block; The second non-consensus node determines, according to the target distance value and the node routing table, a second target non-consensus node corresponding to the target checkpoint block; The second non-consensus node forwards the query request to the second target non-consensus node; 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.

7. The method according to any one of claims 1 to 6, characterized in that: Before the first non-consensus node determines the first target non-consensus node corresponding to each to-be-stored block in the block list according to the distributed hash algorithm and the node routing table corresponding to the non-consensus node cluster, the method further includes: 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; The non-consensus node cluster performs a hierarchical process on the non-consensus nodes in the non-consensus node cluster based on the node distance value, and determines a plurality of buckets according to the hierarchical process result, each bucket containing 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 plurality of buckets.

8. A block storage system based on distributed hashing, characterized in that: The system includes a consensus node and a non-consensus node cluster, wherein 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 connected to the consensus node; wherein: The consensus node is used to synchronize the blocks to be stored in the block list with the first non-consensus node; 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, where the first non-consensus node is any non-consensus node in the non-consensus node cluster connected to the consensus node; 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 body of each block to be stored in the first target non-consensus node corresponding to each block to be stored.

9. 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, the steps of the distributed hash-based block storage method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the distributed hash-based block storage method according to any one of claims 1 to 7 are implemented.

Images