Blockchain block and node mapping method and device, medium and equipment

Abstract

The application provides a block and node mapping method and device of a blockchain, a medium and equipment. The method comprises the following steps: grouping each block, and the number of groups is the same as the number of lightweight nodes in a single shard; for each group, a corresponding copy pointer is constructed, and the number of copy pointers corresponding to each group is the same as the number of shards; each copy pointer corresponding to each group is distributed to each shard, so that each shard obtains one copy pointer distributed from each group; each copy pointer obtained by each shard is one-to-one mapped with each lightweight node in the shard, so that each lightweight node in each shard has a mapping relationship with a copy pointer, and each lightweight node in the same shard can have a mapping relationship with the copy pointers in each group. The embodiment of the application can reduce the data migration amount and overhead in the shard reorganization stage.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method, apparatus, medium, and device for mapping blocks and nodes in a blockchain. Background Technology

[0002] Blockchain allows users to conduct decentralized peer-to-peer transactions in an untrusted environment while ensuring the consistency of distributed data. Blockchain technology combines multiple core computer technologies, including P2P networks, cryptography, and hash algorithms, and features decentralization, transparency, security, and immutability. These characteristics make blockchain a promising area for application in digital currencies, supply chain management, and the Internet of Things. While the blockchain's block-chain structure, storage mechanism, and consensus algorithm ensure decentralization, data security, and transparency, they also lead to scalability limitations in various blockchain systems.

[0003] The emergence of blockchain sharding technology offers a solution to the aforementioned problems. The goal of blockchain sharding is to effectively improve the scalability of a blockchain system while maintaining its decentralization and security. By dividing the blockchain network into multiple independent shards, each shard processes a portion of the transactions and maintains a portion of the blockchain ledger data, enabling the blockchain network to process tasks in parallel. This significantly increases the transaction throughput of the blockchain system and reduces the storage pressure on nodes.

[0004] Currently, blockchain sharding technology still faces some challenges, such as the still high storage pressure on nodes and the large amount of data migration and overhead during sharding and reassembly. Summary of the Invention

[0005] To address at least one of the above technical problems, embodiments of the present invention provide a method, apparatus, medium, and device for mapping blocks and nodes in a blockchain.

[0006] According to a first aspect, the blockchain block-to-node mapping method provided in this embodiment of the invention is executed by a client, the method comprising:

[0007] The blocks are grouped into groups, and the number of groups is the same as the number of lightweight nodes in a single shard.

[0008] For each group, a corresponding replica pointer is constructed, and the number of replica pointers for each group is the same as the number of shards; wherein, the number of lightweight nodes in each shard is the same;

[0009] Each replica pointer corresponding to each group is assigned to each shard, so that each shard receives one replica pointer from each group; wherein, the number of replica pointers received by each shard is the same as the number of lightweight nodes in a single shard;

[0010] Each replica pointer obtained from each shard is mapped one by one to each lightweight node within that shard, so that each lightweight node within each shard has a mapping relationship with a replica pointer, and each lightweight node within the same shard can have a mapping relationship with the replica pointers in each group.

[0011] In one embodiment, after mapping is complete, each lightweight node in each shard can download each block in the group corresponding to the replica pointer that has a mapping relationship with itself, store the downloaded group of blocks, and obtain the blocks of each group through interaction with other lightweight nodes in the same shard. The blocks of each group constitute blockchain data, and a corresponding full-state database is constructed based on the blockchain data.

[0012] In one embodiment, grouping the blocks includes: using a consistent hashing algorithm to map the hash values ​​of each block to different groups, thereby grouping the blocks.

[0013] In one embodiment, each shard also includes full nodes, with the same number of full nodes in each shard. The full nodes are used to store blockchain data including each block and a full-state database corresponding to the blockchain data. After the shard to which they belong is formed, the full nodes synchronize the blockchain data and construct the full-state data. The full nodes and the lightweight nodes constitute a heterogeneous node topology of the blockchain. Each shard performs operations in parallel, and the operations include at least one of transaction verification, block consensus, block on-chaining, and block query based on the full-state database.

[0014] In one embodiment, each lightweight node maintains a routing table that stores the mapping relationships between the lightweight node and a predetermined number of neighboring lightweight nodes and blocks.

[0015] Furthermore, each lightweight node is used during transaction verification to search for blocks that are not mapped to that lightweight node, either by searching according to the mapping in its own maintained routing table or by searching from the full nodes of the same shard.

[0016] In one embodiment, each lightweight node is used to: store the new block after consensus is reached; if the new block has a mapping relationship with the lightweight node, then retain the new block; if the new block does not have a mapping relationship with the lightweight node, then release the new block after a preset time period.

[0017] According to a second aspect, the blockchain block and node mapping device provided in this embodiment of the invention is deployed on a client, the device comprising:

[0018] The block grouping module is used to group the blocks into groups, and the number of groups is the same as the number of lightweight nodes in a single shard.

[0019] The replica construction module is used to construct a corresponding replica pointer for each group, and the number of replica pointers for each group is the same as the number of shards; wherein, the number of lightweight nodes in each shard is the same;

[0020] The replica allocation module is used to allocate the replica pointers corresponding to each group to each shard, so that each shard receives one replica pointer allocated from each group; wherein, the number of replica pointers received by each shard is the same as the number of lightweight nodes in a single shard;

[0021] The mapping establishment module is used to map each replica pointer obtained from each shard to each lightweight node in that shard, so that each lightweight node in each shard has a mapping relationship with a replica pointer, and each lightweight node in the same shard can have a mapping relationship with the replica pointers in each group.

[0022] According to a third aspect, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method provided in the first aspect.

[0023] According to a fourth aspect, the computing device provided in the embodiments of the present invention includes a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method provided in the first aspect.

[0024] The blockchain block-to-node mapping method, apparatus, medium, and device provided in this invention first group the blocks, then construct a corresponding replica pointer for each group, and allocate each replica pointer corresponding to each group to each shard, so that each shard receives one replica pointer allocated from each group. The number of replica pointers received by each shard is the same as the number of lightweight nodes within a single shard. Finally, each replica pointer obtained by each shard is mapped one-to-one with each lightweight node within that shard. After mapping, each lightweight node within each shard has a mapping relationship with one replica pointer, and each lightweight node within the same shard can have a mapping relationship with the replica pointers in each group. The above process provides an efficient data update mechanism, which can quickly establish the correspondence between groups and lightweight nodes. The above process can be applied to shard reorganization scenarios. Using the above process for remapping can minimize the amount of data migration and overhead during the shard reorganization stage, effectively balance system performance and resource utilization, and ensure that the system can maintain an efficient operating state during the reorganization process. Moreover, since lightweight nodes store only one block per group, the storage overhead of node block data can be effectively reduced. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a blockchain block and node mapping method in one embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram illustrating block grouping based on a consistent hashing algorithm in one embodiment of the present invention;

[0027] Figure 3 This is a schematic diagram illustrating an example of a blockchain block and node mapping method in one embodiment of the present invention;

[0028] Figure 4 This is a comparative diagram of full nodes and lightweight nodes in one embodiment of the present invention;

[0029] Figure 5 This is a comparative diagram of the contents stored in a full node and a lightweight node in one embodiment of the present invention;

[0030] Figure 6 This is a schematic diagram of a routing table maintained by a lightweight node in one embodiment of the present invention. Detailed Implementation

[0031] In a first aspect, embodiments of the present invention provide a method for mapping blocks and nodes in a blockchain, wherein the method is executed by a client, see [link to relevant documentation]. Figure 1 The method includes the following steps S110~S140:

[0032] S110. Divide the blocks into groups, and the number of groups is the same as the number of lightweight nodes in a single shard.

[0033] Each block is a separate block within the entire blockchain data; these blocks together form the blockchain data.

[0034] In real-world scenarios, when sharding the nodes of a blockchain, the number of lightweight nodes in each shard is equal, and the number of full nodes in each shard is equal, thus achieving equal-weight sharding.

[0035] For example, in a blockchain, there are 3 shards, and each shard has 2 full nodes and 5 lightweight nodes. In S110, each block will be divided into 5 groups, that is, the number of groups is the same as the number of lightweight nodes in each shard.

[0036] In one embodiment, a consistent hashing algorithm is used to map the hash values ​​of each block to different groups, thereby achieving the grouping of the blocks.

[0037] In other words, each block naturally has its own corresponding hash value. After inputting the hash value of each block into the consistent hashing algorithm, a value that maps to a certain group is obtained, thereby classifying the block into that group.

[0038] Among them, see Figure 2 Consistent hashing, due to its ring structure, is highly adaptable to the dynamic addition or removal of nodes, making it well-suited for dynamically changing blockchain networks. It can adapt to node changes through simple remapping without requiring global data migration. Simultaneously, blocks are mapped relatively evenly across different groups.

[0039] The consistent hashing algorithm can be a consistent SHA-256 hash function.

[0040] S120. For each group, construct a corresponding replica pointer, and the number of replica pointers for each group is the same as the number of shards; wherein, the number of lightweight nodes in each shard is the same;

[0041] That is, a corresponding replica pointer can be built for the i-th group, where j is the number of shards. See also Figure 3 The number of replica pointers corresponding to each group is 3.

[0042] S130. Assign each replica pointer corresponding to each group to each shard, so that each shard receives one replica pointer assigned by each group; wherein, the number of replica pointers received by each shard is the same as the number of lightweight nodes in a single shard;

[0043] For example, the three replica pointers corresponding to each group are assigned to three shards, so that each shard can get one replica pointer from each group. Since there are five groups, each shard can get five replica pointers from the five groups.

[0044] It is evident that the number of replica pointers, the number of groups, and the number of lightweight nodes within a single shard are all the same for each shard.

[0045] It is understood that the embodiments of the present invention implement the operation of copying blocks within a group through a replica pointer, but in fact, no actual block copying is performed; only a replica pointer corresponding to the group is created.

[0046] S140. Map each replica pointer obtained from each shard to each lightweight node in that shard, so that each lightweight node in each shard has a mapping relationship with a replica pointer, and each lightweight node in the same shard can have a mapping relationship with the replica pointers in each group.

[0047] For example, each shard's five replica pointers are mapped one-to-one with the five lightweight nodes within that shard. This means each lightweight node in each shard corresponds to one replica pointer, and the five lightweight nodes within the same shard can have mapping relationships with replicas in five groups. Thus, each lightweight node in a shard can download the blocks from the group corresponding to its mapped replica pointer, i.e., download a block group. The five lightweight nodes within the same shard download five different block groups, which are the five groups mentioned above, forming the blockchain data.

[0048] The one-to-one mapping process described above can be random, meaning that the five groups and five lightweight nodes are randomly mapped one-to-one.

[0049] The mapping or correspondence between lightweight nodes and replica pointers is actually the mapping between lightweight nodes and block groups, i.e., groups.

[0050] The mapping process in S140 above can be implemented using the CRUSH algorithm.

[0051] Understandably, the above S110~S140 can also be applied to the scenario of periodic reassembly of shards. Since periodic reassembly of shards involves large-scale data migration, using S110~S140 for grouping and remapping of lightweight nodes during the reassembly phase can minimize the amount of data migration and overhead during the shard reorganization phase, effectively balance system performance and resource utilization, and ensure that the system can maintain an efficient operating state during the reassembly process.

[0052] Currently, during the sharding and reorganization phase, the redistribution of nodes causes large-scale data migration, resulting in significant reconstruction overhead for the system. In this embodiment of the invention, the remapping between groups and lightweight nodes is achieved through the above-described S110~S140 processes, avoiding the high overhead caused by blockchain data reconstruction and effectively reducing the storage overhead of node block data.

[0053] As can be seen, the above steps S110~S140 provide an efficient data update mechanism that can quickly establish the correspondence between groups and lightweight nodes.

[0054] In one embodiment, after mapping is complete, each lightweight node in each shard can download each block in the group corresponding to the replica pointer that has a mapping relationship with itself, store the downloaded group of blocks, and obtain the blocks of each group through interaction with other lightweight nodes in the same shard. The blocks of each group constitute blockchain data, and a corresponding full-state database is constructed based on the blockchain data.

[0055] In other words, after the mapping relationship is established, each lightweight node within each shard can download the blocks in the group corresponding to its mapped replica pointer, i.e., the block group corresponding to its mapped replica pointer. The lightweight node stores the downloaded block group after downloading. Lightweight nodes within the same shard can interact, allowing each node to obtain the various block groups and thus the entire blockchain data. Based on this entire blockchain data, a corresponding full-state database is then built, storing state information such as logs.

[0056] In this process, after each lightweight node in each shard downloads the corresponding block group and builds the full-state database, each shard can perform operations in parallel, such as transaction verification, block consensus, block uploading, and block querying. Transaction verification is implemented based on the full-state database.

[0057] Because lightweight nodes store a full-state database corresponding to the blockchain data, the integrity and consistency of state information are guaranteed, enabling rapid transaction verification and thus improving transaction verification efficiency. Since lightweight nodes maintain a full-state database corresponding to the blockchain data, cross-shard transactions can be processed within the same shard based on the state data in the full-state database. This ensures that the state data of the transaction's recipient and sender can be quickly obtained within the same shard, reducing inter-shard communication overhead and guaranteeing high-efficiency transaction processing.

[0058] Currently, blockchain sharding technology faces several challenges: Existing blockchain sharding protocols employ a state sharding mechanism to reduce the storage overhead of blockchain nodes. This means that the state database within a node stores only a portion of the state information, not the full state information corresponding to the blockchain data. This strategy results in incomplete state data stored in each shard, introducing additional processing costs for cross-shard transactions and block verification. In this embodiment of the invention, both full nodes and lightweight nodes maintain a full-state database. This full-state database stores complete state information corresponding to the blockchain data, thus reducing processing costs for cross-shard transactions and block verification.

[0059] In one embodiment, each shard also includes full nodes, with the same number of full nodes in each shard. The full nodes are used to store blockchain data including each block and a full-state database corresponding to the blockchain data. After the shard to which they belong is formed, the full nodes synchronize the blockchain data and construct the full-state data. The full nodes and the lightweight nodes constitute a heterogeneous node topology of the blockchain. Each shard performs operations in parallel, and the operations include at least one of transaction verification, block consensus, block on-chaining, and block query based on the full-state database.

[0060] In other words, each shard includes full nodes and lightweight nodes. Full nodes store the entire blockchain data and the aforementioned full-state database, and they download the blockchain data immediately after the shard is formed. Lightweight nodes, on the other hand, are only downloaded after the aforementioned mapping relationship is established, and they can only download one block group at a time. Full nodes and lightweight nodes constitute the heterogeneous node topology of the blockchain.

[0061] The difference between full nodes and lightweight nodes lies in the following: lightweight nodes require less storage space than full nodes; during verification, lightweight nodes need to search for blocks they haven't stored themselves based on the router or search for the required blocks from the full node. Compared to lightweight nodes, full nodes operate more independently and efficiently.

[0062] See Figure 4The lightweight node lwNode only stores some blocks such as 1, 5, 9, etc., while the full node fNode stores all blocks such as 1, 2, 3, etc. It can be seen that the coverage of the full node is greater than that of the lightweight node.

[0063] See Figure 5 Both lightweight nodes and full nodes store the full state database, but lightweight nodes only store the blocks in Groupi, while full nodes store all blocks from 1 to n.

[0064] In order to achieve efficient transaction verification, both full nodes and lightweight nodes store a complete full-state database of blockchain data.

[0065] Full nodes store blockchain data and therefore do not involve mapping and allocation with blocks. Lightweight nodes store only one set of blocks. Compared to full nodes, lightweight nodes reduce storage overhead to [a lower percentage]. Here, [a] represents the number of blocks, [b] represents the block size, and [c] represents the number of blocks.

[0066] In one embodiment, each lightweight node maintains a routing table that stores the mapping relationships between the lightweight node and a predetermined number of neighboring lightweight nodes and blocks.

[0067] For example, the routing table maintained by the first lightweight node in a shard includes the mapping relationship between the first lightweight node and the block, the mapping relationship between the second lightweight node in the shard and the block, and the mapping relationship between the third lightweight node in the shard and the block.

[0068] For example, the routing table maintained by the second lightweight node in a shard includes the mapping relationship between the second lightweight node and the block, the mapping relationship between the third lightweight node and the block in the shard, and the mapping relationship between the fourth lightweight node and the block in the shard.

[0069] Furthermore, each lightweight node can be used to: during the transaction verification process, when it is necessary to find a block that does not have a mapping relationship with the lightweight node, search according to the mapping relationship in its own maintained routing table or search from the full nodes of the same shard.

[0070] In other words, since each lightweight node maintains a routing table, during transaction verification, if a lightweight node needs to find a block that it doesn't store, it can determine which lightweight node stores the block based on the mapping in its routing table, and then search for the required block from that node. If there's no corresponding mapping in the router, it can search the routing tables of other lightweight nodes, eventually finding the required block, thus achieving a time complexity of [missing information - likely a specific time complexity].

[0071] See Figure 6 In the routing table, only the mapping relationship between node N3 and each block in group N2 is given. In fact, the mapping relationship between node N4, N5 and the blocks can also be set.

[0072] In one embodiment, each lightweight node can be used to: store the new block after consensus is reached; if the new block has a mapping relationship with the lightweight node, then retain the new block; if the new block does not have a mapping relationship with the lightweight node, then release the new block after a preset time period.

[0073] In other words, for a new consensus block, the new block is temporarily stored in each lightweight node. However, if, according to S110~S140 above, there is no mapping relationship between the new block and the lightweight node, the lightweight node will release the new block. If there is a mapping relationship between the new block and the lightweight node, the lightweight node will retain the new block.

[0074] In summary, the embodiments of the present invention can reduce the storage overhead of lightweight nodes and minimize the amount of data migration during fragment reassembly.

[0075] Secondly, embodiments of the present invention provide a blockchain block and node mapping device, the device being deployed on a client, the device comprising:

[0076] The block grouping module is used to group the blocks into groups, and the number of groups is the same as the number of lightweight nodes in a single shard.

[0077] The replica construction module is used to construct a corresponding replica pointer for each group, and the number of replica pointers for each group is the same as the number of shards; wherein, the number of lightweight nodes in each shard is the same;

[0078] The replica allocation module is used to allocate the replica pointers corresponding to each group to each shard, so that each shard receives one replica pointer allocated from each group; wherein, the number of replica pointers received by each shard is the same as the number of lightweight nodes in a single shard;

[0079] The mapping establishment module is used to map each replica pointer obtained from each shard to each lightweight node in that shard, so that each lightweight node in each shard has a mapping relationship with a replica pointer, and each lightweight node in the same shard can have a mapping relationship with the replica pointers in each group.

[0080] In one embodiment, after mapping is complete, each lightweight node in each shard can download each block in the group corresponding to the replica pointer that has a mapping relationship with itself, store the downloaded group of blocks, and obtain the blocks of each group through interaction with other lightweight nodes in the same shard. The blocks of each group constitute blockchain data, and a corresponding full-state database is constructed based on the blockchain data.

[0081] In one embodiment, the block grouping module is specifically used to: map the hash values ​​of each block to different groups using a consistent hashing algorithm, thereby achieving the grouping of the blocks.

[0082] In one embodiment, each shard also includes full nodes, with the same number of full nodes in each shard. The full nodes are used to store blockchain data including each block and a full-state database corresponding to the blockchain data. After the shard to which they belong is formed, the full nodes synchronize the blockchain data and construct the full-state data. The full nodes and the lightweight nodes constitute a heterogeneous node topology of the blockchain. Each shard performs operations in parallel, and the operations include at least one of transaction verification, block consensus, block on-chaining, and block query based on the full-state database.

[0083] In one embodiment, each lightweight node maintains a routing table that stores the mapping relationships between the lightweight node and a predetermined number of neighboring lightweight nodes and blocks.

[0084] In one embodiment, each lightweight node is used to: during the transaction verification process, when it is necessary to find a block that does not have a mapping relationship with the lightweight node, search according to the mapping relationship in its own maintained routing table or search from the full nodes of the same shard.

[0085] In one embodiment, each lightweight node is used to: store the new block after consensus is reached; if the new block has a mapping relationship with the lightweight node, then retain the new block; if the new block does not have a mapping relationship with the lightweight node, then release the new block after a preset time period.

[0086] It is understood that explanations, specific implementation methods, beneficial effects, examples, etc. of the contents of the apparatus provided in the embodiments of the present invention can be found in the corresponding parts of the method provided in the first aspect, and will not be repeated here.

[0087] Thirdly, embodiments of the present invention provide a computer-readable medium storing computer instructions, which, when executed by a processor, cause the processor to perform the method provided in the first aspect.

[0088] Specifically, a system or apparatus equipped with a storage medium may be provided, on which software program code implementing the functions of any of the embodiments described above is stored, and the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage medium.

[0089] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0090] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0091] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0092] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion module connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion module execute some and all of the actual operations, thereby realizing the function of any of the above embodiments.

[0093] It is understood that explanations, specific implementation methods, beneficial effects, examples, etc. of the contents in the computer-readable medium provided in the embodiments of the present invention can be found in the corresponding parts of the method provided in the first aspect, and will not be repeated here.

[0094] Fourthly, one embodiment of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method of any embodiment of the specification.

[0095] It is understood that explanations, specific implementation methods, beneficial effects, examples, etc. of the computing device provided in the embodiments of the present invention can be found in the corresponding parts of the method provided in the first aspect, and will not be repeated here.

[0096] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0097] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, widgets, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0098] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for mapping blocks and nodes in a blockchain, characterized in that, The method is executed by the client, and the method includes: The blocks are grouped into groups, and the number of groups is the same as the number of lightweight nodes in a single shard. For each group, a corresponding replica pointer is constructed, and the number of replica pointers for each group is the same as the number of shards; wherein, the number of lightweight nodes in each shard is the same; Each replica pointer corresponding to each group is assigned to each shard, so that each shard receives one replica pointer from each group; wherein, the number of replica pointers received by each shard is the same as the number of lightweight nodes in a single shard; Each replica pointer obtained from each shard is mapped one by one to each lightweight node in that shard, so that each lightweight node in each shard has a mapping relationship with a replica pointer, and each lightweight node in the same shard can have a mapping relationship with the replica pointers in each group. After mapping is complete, each lightweight node in each shard can download each block in the group corresponding to the replica pointer that has a mapping relationship with itself, store the downloaded group of blocks, and obtain the blocks of each group through interaction with other lightweight nodes in the same shard. The blocks of each group constitute blockchain data, and a corresponding full-state database is built based on the blockchain data. Each shard also includes full nodes, and the number of full nodes in each shard is the same. The full nodes are used to store blockchain data including each block and the full state database corresponding to the blockchain data. After the shard to which they belong is formed, the full nodes synchronize the blockchain data and construct the full state data. The full nodes and the lightweight nodes constitute the heterogeneous node topology of the blockchain. Each shard performs operations in parallel, and the operations include at least one of the following based on the full-state database: transaction verification, block consensus, block on-chaining, and block query.

2. The method according to claim 1, characterized in that, The step of grouping the blocks includes: using a consistent hashing algorithm to map the hash values ​​of each block to different groups, thereby grouping the blocks.

3. The method of claim 1, wherein, Each lightweight node maintains a routing table that stores the mapping relationships between the lightweight node and a predetermined number of neighboring lightweight nodes and blocks.

4. The method of claim 3, wherein, Each lightweight node is used for: during transaction verification, when it is necessary to find a block that does not have a mapping relationship with the lightweight node, to search according to the mapping relationship in its own maintained routing table or to search from the full nodes of the same shard.

5. The method of claim 1, wherein, Each lightweight node is used to: store the new block after consensus is reached; if the new block has a mapping relationship with the lightweight node, then the new block is retained; if the new block does not have a mapping relationship with the lightweight node, then the new block is released after a preset time period. 6.A block and node mapping device of a blockchain, characterized in that, The device is deployed on a client, and the device includes: The block grouping module is used to group the blocks into groups, and the number of groups is the same as the number of lightweight nodes in a single shard. The replica construction module is used to construct a corresponding replica pointer for each group, and the number of replica pointers for each group is the same as the number of shards; wherein, the number of lightweight nodes in each shard is the same; The replica allocation module is used to allocate the replica pointers corresponding to each group to each shard, so that each shard receives one replica pointer allocated from each group; wherein, the number of replica pointers received by each shard is the same as the number of lightweight nodes in a single shard; The mapping establishment module is used to map each replica pointer obtained from each shard to each lightweight node within that shard, so that each lightweight node within each shard has a mapping relationship with a replica pointer, and each lightweight node within the same shard can have a mapping relationship with the replica pointers in each group; After mapping is complete, each lightweight node in each shard can download each block in the group corresponding to the replica pointer that has a mapping relationship with itself, store the downloaded group of blocks, and obtain the blocks of each group through interaction with other lightweight nodes in the same shard. The blocks of each group constitute blockchain data, and a corresponding full-state database is built based on the blockchain data. Each shard also includes full nodes, and the number of full nodes in each shard is the same. The full nodes are used to store blockchain data including each block and the full state database corresponding to the blockchain data. After the shard to which they belong is formed, the full nodes synchronize the blockchain data and construct the full state data. The full nodes and the lightweight nodes constitute the heterogeneous node topology of the blockchain. Each shard performs operations in parallel, and the operations include at least one of the following based on the full-state database: transaction verification, block consensus, block on-chaining, and block query.

7. A computer readable storage medium characterized by It stores a computer program that, when executed in a computer, causes the computer to perform the method described in any one of claims 1 to 6.

8. A computing device, comprising: The method includes a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in any one of claims 1 to 6.

Images