A node cooperation storage method and system for alliance chain ledger data

Abstract

The application discloses a kind of node cooperation storage methods and systems for alliance chain ledger data, method includes: for the node in alliance chain group, the performance of node is calculated and is sorted by strength, and the node of early rotation in order is used as main node;Main node will group inside transaction generation collection and package and submit to consensus network;Main node synchronously obtains new block, according to the hash data of block number, the block is determined corresponding by first mapping PG;The straw value of corresponding node is obtained by using pseudo-random hash algorithm to PG number, node ID and the weight of each node copy number;The main account book and the second mapping of sub-account book are stored to the different node of maximum straw value obtained each time. By the technical scheme of the application, the storage pressure of a single node is reduced, the storage performance of alliance chain is improved, the transaction query efficiency of block chain is improved, and the management efficiency of node and block is improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a node collaborative storage method and a node collaborative storage system for consortium blockchain ledger data. Background Technology

[0002] Blockchain technology enables trustworthy and peer-to-peer value transfer between distrustful participants without the aid of a trusted third party, and has therefore experienced rapid development and widespread application in recent years.

[0003] As blockchain applications deepen, enterprises' demands for them are increasing. Public and private blockchains, due to their respective shortcomings, are not suitable for enterprise-level applications, leading to the emergence of consortium blockchains. Consortium blockchains, with their partial centralization and ease of consensus, are well-suited for enterprise-level applications. However, as consortium blockchain applications deepen, ledger data will expand rapidly. Ordinary users will find it difficult to provide the hardware support for such large-capacity storage, resulting in a decreasing number of high-strength nodes capable of participating in consortium blockchain maintenance, leading to the gradual centralization of the consortium blockchain ledger. In this context, having a complete ledger jointly stored by nodes within a group, reducing the storage burden on individual nodes, has become an important solution. This storage concept shows great promise in future blockchain applications of all sizes.

[0004] like Figure 1 As shown, in the typical structure of a scalable consortium blockchain, there are several network maintenance modes in the mainstream architecture. One mode is where one node in the group participates in the maintenance of the entire network, while other nodes are only responsible for simple business queries. Another mode is where all nodes participate in the maintenance of the blockchain network.

[0005] Furthermore, current research on collaborative storage data allocation algorithms within blockchain groups primarily employs a consistent hashing strategy. While consistent hashing rings can meet load balancing requirements to some extent, they also have certain drawbacks. First, when there are few nodes in the group, the distribution of nodes on the hash ring may be uneven, resulting in areas that are either too sparse or too dense. Even with the addition of more virtual nodes, the large range of the hash function means that adding virtual nodes can only achieve a limited degree of coverage. Additionally, if a node leaves the group, the consistent hashing ring's data migration strategy directly migrates the data from the leaving node to the nearest neighboring node. While this facilitates data migration to some extent, it easily leads to uneven data distribution and excessive data load on individual nodes. Summary of the Invention

[0006] To address the aforementioned issues, this invention provides a node collaborative storage method and system for consortium blockchain ledger data. By starting with the ledger storage architecture of the consortium blockchain, the required network-wide block ledger data is shared and stored by the entire consortium blockchain group. This reduces the storage pressure on individual nodes, improves the storage performance of the consortium blockchain, and enhances the transaction query efficiency. By employing a two-level mapping strategy and introducing a Placement Group (PG), the management efficiency of nodes and blocks can be improved. Combined with a weighted hash data distribution algorithm, the storage capacity of nodes is rationally utilized, mapping multi-replica file data to all nodes. This ensures that data is evenly distributed throughout the entire consortium blockchain group, and also achieves balanced data distribution and minimal data migration when nodes dynamically join or leave the group.

[0007] To achieve the above objectives, the present invention provides a node collaborative storage method for consortium blockchain ledger data, comprising:

[0008] For nodes within a consortium blockchain group, the performance of the nodes is calculated and the nodes are ranked according to their performance strength. A preset proportion of nodes with the highest performance ranking are rotated to become the master nodes.

[0009] The master node collects and packages the transactions generated within the consortium blockchain group and submits them to the consensus network of the entire network;

[0010] The master node synchronously obtains new blocks from the entire network, and determines the corresponding placement group (PG) of the block through the first mapping based on the hash data of the block number.

[0011] The pseudo-random hash algorithm is used to perform r+1 random number calculations on the PG number, node ID, and number of secondary ledger files r, and the random number straw value of the corresponding node is calculated based on the weight of each node in the consortium chain group.

[0012] The main ledger file and r secondary ledger files of the block are mapped and stored for the second time to the different nodes with the largest straw values ​​obtained in each calculation.

[0013] In the above technical solution, preferably, the node collaborative storage method for consortium blockchain ledger data further includes: when a node leaves the consortium blockchain group, querying the PG corresponding to the node, and deleting the node information of the node from the cluster map provided by the cluster monitor;

[0014] Recalculate the straw value of the PG corresponding to the current node on other nodes, map the PG to the node with the largest straw value, and transfer the blocks in the PG to the corresponding node.

[0015] In the above technical solution, preferably, the node collaborative storage method for consortium blockchain ledger data further includes:

[0016] When a new node joins the consortium blockchain group, the cluster map registers the node information of the new node;

[0017] Calculate the straw value of each PG to the new node. If the straw value of each PG to the new node is greater than the straw value of its current corresponding node, then the blocks in the corresponding PG are transferred to the new node; otherwise, no transfer is required.

[0018] In the above technical solution, preferably, the specific method for ranking the computing nodes by performance and selecting a predetermined proportion of nodes with the highest performance as master nodes includes:

[0019] The standardized node parameters of the node are calculated using the following standardized calculation formula:

[0020]

[0021] Where Ti is the standardized node parameter, T r For standardized node parameters, T min The minimum value of the same parameter in the consortium blockchain group. This is the average value of all parameters;

[0022] The performance value of the node is calculated using the following formula, based on the node's storage capacity, CPU parameters, disk I / O rate, memory, and network bandwidth:

[0023] P i =k1S i +k2C i +k3M i +k4D i +k5W i

[0024] Among them, P i S represents the performance value of the node, k1…k5 are the weights of each parameter, and S represents the performance value of the node. i For storage capacity, C i D is the product of the number of CPUs and the CPU processing frequency. i For disk I / O speed, M i For memory size, W i For network bandwidth;

[0025] According to the performance value P i All nodes are sorted from strongest to weakest. Among the nodes with the highest performance, the first-ranked node becomes the master node, and after each round of block production, the next-ranked node becomes the master node.

[0026] If a node crashes while serving as the master node, the next-ranked node will immediately take over as the master node. The crashed node will not participate in the master node rotation process for a preset time threshold. After the preset time threshold is exceeded, the nodes in the current consortium chain group will vote to determine whether the current node can participate in the master node rotation.

[0027] In the above technical solution, preferably, the specific process by which the master node collects, packages, and submits transactions generated within the consortium blockchain group to the consensus network of the entire network includes:

[0028] The master node listens to all transactions initiated by all nodes in the current consortium blockchain group, collects the listened transactions, packages them into a transaction set, and submits them to the main chain of the consortium blockchain at a preset frequency.

[0029] After reaching a consensus across the entire network, a new block is generated and distributed to the corresponding nodes of each consortium blockchain for storage based on the information in the new block.

[0030] In the above technical solution, preferably, the specific process of determining the corresponding placement group (PG) of the block through the first mapping based on the hash data of the block number includes:

[0031] A hash value is obtained by performing a hash calculation on the block height of the block to be allocated. The hash value is then moduloed by the number of PGs to obtain the PG corresponding to the block. Here, PG is a set of block objects mapped by the above hash algorithm, and the number of PGs is preset according to the number of secondary ledger files based on the number of nodes.

[0032] In the above technical solution, preferably, the specific process of using a pseudo-random hash algorithm to perform r+1 random number calculations on the PG number, node ID, and the number r of secondary ledger files, and calculating the straw value of the corresponding node based on the weight of each node in the consortium blockchain group includes:

[0033] Based on the PG number, node ID, number of secondary ledger files r, and node weight, a weighted random number straw value is calculated for each node using a pseudo-random hash function:

[0034] straw=jenkins hash(PGID,PID,i)*P_weight

[0035] Where Jenkins hash is the pseudo-random number generation function, PGID is the placement group PG number, PID is the node ID, and P_weight is the weight of the current node;

[0036] After each calculation, the pseudo-random hash function is executed again after i+1, until r+1 calculations are performed based on the number of secondary ledger files, so that the primary ledger file and all secondary ledger files can find the corresponding node based on the calculated straw value.

[0037] In the above technical solution, preferably, the specific process of mapping and storing the main ledger file and r secondary ledger files of the block to the different nodes with the largest straw values ​​obtained in each calculation for the second time includes:

[0038] Select the node with the largest straw value obtained in the first calculation as the storage node for the main ledger file of the block in that PG group;

[0039] Based on the node with the largest straw value obtained in the next calculation that is different from the previous one, store one of the secondary ledger files into that node, until all the secondary ledger files are stored into different nodes in sequence.

[0040] In the above technical solution, preferably, the node collaborative storage method for consortium blockchain ledger data further includes:

[0041] Upon receiving a transaction query instruction, the node enters the local cache pool to search. If the cache is hit, the transaction result is returned directly. If the cache is not hit, the node queries the block information to obtain the PG number corresponding to the block, finds the node corresponding to the PG number through the cluster map, and enters the node to search for the corresponding block content.

[0042] The local cache pool sets a time threshold and an access count threshold through a cache replacement algorithm. Cache content that is not hit within the time threshold is removed from the local cache pool. When new block content is accessed, it replaces the cache content in the local cache pool that has been accessed less than the access count threshold.

[0043] This invention also proposes a node collaborative storage system for consortium blockchain ledger data, applying the node collaborative storage method for consortium blockchain ledger data disclosed in any of the above technical solutions, including:

[0044] The group node architecture module is used to calculate the performance of nodes within a consortium blockchain group and sort the nodes by performance strength. The nodes with the highest performance ranking are rotated to become the master nodes.

[0045] The local transaction submission module is used to collect and package transactions generated within the consortium blockchain group and submit them to the consensus network of the entire network.

[0046] In the first group mapping module, the master node synchronously obtains new blocks from the entire network and determines the corresponding placement group (PG) of the block through the first mapping based on the hash data of the block number.

[0047] The weight random calculation module is used to perform r+1 random number calculations on the PG number, node ID and the number r of secondary ledger files using a pseudo-random hash algorithm, and to calculate the random number straw value of the corresponding node based on the weight of each node in the consortium chain group.

[0048] The secondary balanced mapping module is used to map and store the main ledger file and r secondary ledger files of the block to the different nodes with the largest straw values ​​obtained in each calculation for the second time.

[0049] Compared with existing technologies, the beneficial effects of this invention are as follows: By starting with the ledger storage architecture of the consortium blockchain, the ledger of all network blocks required within the group is shared by the entire consortium blockchain group for storage, reducing the storage pressure on individual nodes, improving the storage performance of the consortium blockchain, and improving the transaction query efficiency of the blockchain. By adopting a two-level mapping strategy and introducing a placement group (PG), the management efficiency of nodes and blocks is improved. Combined with a weighted hash data distribution algorithm, the storage capacity of nodes is rationally utilized, and multi-replica file data is mapped to all nodes, which can ensure that the data is evenly distributed throughout the entire consortium blockchain group. At the same time, it can also achieve balanced data distribution and less data migration when nodes dynamically leave or join. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of a scalable consortium blockchain structure disclosed in an embodiment of the prior art;

[0051] Figure 2 This is a flowchart illustrating a node collaborative storage method for consortium blockchain ledger data, as disclosed in one embodiment of the present invention.

[0052] Figure 3 This is a schematic diagram of the storage process of a new block disclosed in one embodiment of the present invention;

[0053] Figure 4 This is a schematic diagram of a load balancing storage process involving two mappings, as disclosed in an embodiment of the present invention.

[0054] Figure 5 This is a schematic diagram of the node exiting block transfer process disclosed in one embodiment of the present invention;

[0055] Figure 6 This is a schematic diagram of the process of adding a node to a block transfer according to an embodiment of the present invention;

[0056] Figure 7This is a schematic diagram of a block query process disclosed in one embodiment of the present invention;

[0057] Figure 8 This is a schematic diagram of a node collaborative storage system for consortium blockchain ledger data, as disclosed in one embodiment of the present invention.

[0058] In the diagram, the correspondence between the components and the reference numerals is as follows:

[0059] 1. Group node architecture module, 2. Local transaction submission module, 3. Primary grouping mapping module, 4. Weight random calculation module, 5. Secondary equilibrium mapping module. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] The present invention will now be described in further detail with reference to the accompanying drawings:

[0062] like Figure 2 As shown, a node collaborative storage method for consortium blockchain ledger data provided by the present invention includes:

[0063] For nodes within a consortium blockchain group, the performance of the nodes is calculated and the nodes are ranked according to their performance strength. A preset proportion of nodes with the highest performance ranking are rotated to become the master nodes.

[0064] The master node collects and packages the transactions generated within the consortium blockchain group and submits them to the consensus network of the entire network;

[0065] The master node synchronously obtains new blocks from the entire network and determines the corresponding placement group (PG) for the block through the first mapping based on the hash data of the block number.

[0066] The pseudo-random hash algorithm is used to perform r+1 random number calculations on the PG number, node ID, and number of secondary ledger files r, and the random number straw value of the corresponding node is calculated based on the weight of each node in the consortium blockchain group.

[0067] The main ledger file and r secondary ledger files of the block are mapped and stored a second time to the different nodes with the largest straw value obtained in each calculation.

[0068] In this implementation, by starting with the ledger storage architecture of the consortium blockchain, the ledger of all network blocks required within the group is shared by the entire consortium blockchain group for storage. This reduces the storage pressure on individual nodes, improves the storage performance of the consortium blockchain, and enhances the transaction query efficiency of the blockchain. By adopting a two-level mapping strategy and introducing a Placement Group (PG), the management efficiency of nodes and blocks is improved. Combined with a weighted hash data distribution algorithm, the storage capacity of nodes is rationally utilized, and multi-replica file data is mapped to all nodes. This ensures that data is evenly distributed throughout the entire consortium blockchain group, and also achieves balanced data distribution and minimal data migration when nodes dynamically leave or join.

[0069] Specifically, this invention designs a group collaborative storage scheme for consortium blockchains, whereby the entire consortium blockchain group jointly stores the required network-wide block ledger data. This reduces the storage pressure on individual nodes, improves the storage performance of the consortium blockchain, and enhances the efficiency of blockchain transaction queries. Based on the network maintenance models of various mainstream consortium blockchain architectures, this invention is applicable to the structure of most consortium blockchain architectures. In specific implementation, taking the model where one node in the group participates in network-wide maintenance and other nodes are only responsible for simple business queries as an example, this invention's node collaborative storage method for consortium blockchain ledger data will be specifically explained.

[0070] In this consortium blockchain, the master node participates in the block consensus process to obtain the latest blocks from the entire network. These blocks are then jointly stored by all nodes within the group, rather than each node storing a separate ledger or relying solely on the master node to store the entire ledger. Because consortium blockchains allow for greater control over the network, nodes within the group are generally from the same unit or organization, rather than being randomly assigned. Nodes within the group require a strict authentication mechanism, resulting in relatively higher trust levels among nodes compared to conventional blockchain nodes. This invention only studies the storage network and does not delve into how consortium blockchain groups are divided and access is granted.

[0071] Regarding the selection of the master node in the storage architecture, the master node is responsible for packaging and broadcasting new transactions generated within the group to the consensus network, as well as obtaining the latest blocks from the entire network and distributing the block files among all nodes in the consortium blockchain group using a certain algorithm. Therefore, a relatively high-performance node is needed to fulfill this role. This invention uses node performance calculation to competitively select the master node. Since new nodes joining the consortium blockchain require a strict admission mechanism, i.e., strict identity verification, the nodes within the group are more trustworthy than those in traditional blockchains. Because this invention only considers the storage network, the verification mechanism for new node joining is not elaborated upon. Node performance is specifically determined by the node's hard disk storage capacity, CPU parameters, disk I / O rate, memory, network bandwidth, etc. Since the dimensions of each node parameter are different, directly adding the parameters together is not appropriate; therefore, standardized calculations are needed for the node performance parameters.

[0072] In the above embodiments, preferably, the standardized node parameters of the nodes are calculated using the following standardized calculation formula:

[0073]

[0074] Where Ti is the standardized node parameter, T r For standardized node parameters, T min This represents the minimum value of the same parameter within the consortium blockchain group. This is the average value of each parameter; that is, the node's storage capacity, CPU parameters, disk I / O rate, memory and network bandwidth are standardized using the above standardized calculation formulas, and the node's performance value is calculated by substituting the standardized parameters into the following formula.

[0075] Based on the node's storage capacity, CPU parameters, disk I / O rate, memory, and network bandwidth, the node's performance value is calculated by weighting the various performance parameters according to their importance using the following formula:

[0076] P i =k1S i +k2C i +k3M i +k4D i +k5W i

[0077] Among them, P i S represents the performance value of the node, k1…k5 are the weights of each parameter, and S represents the performance value of the node. i For storage capacity, C i D is the product of the number of CPUs and the CPU processing frequency. i For disk I / O speed, M i For memory size, W i For network bandwidth; wherein, the allocation of weights k1…k5 according to the master node task requirements of the present invention can be set to (0.2, 0.3, 0.2, 0.2, 0.1) respectively;

[0078] According to the performance value P i All nodes are sorted from strongest to weakest. Among the nodes with the highest performance, the node ranked first becomes the master node, and after each round of block production, the node ranked next becomes the master node.

[0079] Specifically, to avoid the centralization problem within the group caused by high-performance nodes dominating as master nodes for extended periods after performance ranking, this solution uses storage performance as the ranking criterion to design a round-robin master node strategy. That is, under the premise of performance advantage, a predetermined proportion (e.g., 50%) of the nodes with the highest performance ranking take turns becoming the master node. The node ranked first initially serves as the master node, and after each round of block production, the next node takes over. Preferably, when there are fewer than four nodes in the group, all nodes in the group participate in the round-robin.

[0080] If a node frequently crashes while serving as the master node, it will inevitably affect the normal operation of the blockchain. If a node crashes while serving as the master node, the next-ranked node will immediately take over as the master node. The crashed node will not participate in the master node rotation process for a preset time threshold to prevent frequent problems from crashing and affecting the normal operation of the blockchain. After the preset time threshold is exceeded, the nodes in the current consortium blockchain group will vote to determine whether the current node can participate in the master node rotation.

[0081] like Figure 3 As shown, in the above implementation, preferably, the specific process by which the master node collects, packages, and submits transactions generated within the consortium blockchain group to the consensus network of the entire network includes:

[0082] The master node listens to all transactions initiated by all nodes in the current consortium blockchain group, collects the listened transactions, packages them into a transaction set, and submits them to the main chain of the consortium blockchain at a preset frequency.

[0083] After reaching a consensus across the entire network, a new block is generated and distributed to the corresponding nodes of each consortium blockchain for storage based on the information in the new block.

[0084] Specifically, regarding local transactions, since non-master nodes do not directly participate in the overall consensus network, all transactions within the group are submitted to the consensus network by the master node. The master node listens to transactions initiated by all nodes within the group, collects the transactions, packages them into transaction sets, and submits them to the consortium blockchain main chain at a certain frequency. When the transaction frequency within the group is high, the master node's submission frequency also increases accordingly. Each transaction is signed by the initiating node; the master node is only responsible for organizing and submitting them. All transactions within the group, like other transactions across the entire network, generate new blocks after network-wide consensus and are then distributed to the various nodes within the group for storage.

[0085] like Figure 4 As shown, in the above embodiment, preferably, the specific process of determining the corresponding placement group (PG) of a block through the first mapping based on the hash data of the block number includes:

[0086] The block height of the block to be allocated is hashed to obtain a hash value. The hash value is then moduloed by the number of PGs to obtain the PG corresponding to the block. Here, PG is the set of block objects mapped by the above hash algorithm, and the number of PGs is preset according to the number of secondary ledger files based on the number of nodes.

[0087] Specifically, this invention employs a two-level mapping strategy combined with a hash-based data distribution algorithm to map data to all nodes based on weights. The probability of selecting each target storage object is relatively independent, thus ensuring that data is evenly distributed throughout the cluster. Furthermore, it achieves balanced data distribution and minimizes data migration even when nodes dynamically join or leave the cluster.

[0088] The consortium blockchain storage architecture uses blocks as the basic unit of division. Blocks, after being broadcast and authenticated across the entire network, are the basic unit of storage operations. The master node synchronizes new blocks on the main chain, and within the group, blocks are distributed and stored across all nodes according to the designed data allocation strategy. The main components are nodes (Clients) and a cluster monitor (Monitor). Data storage and query requests initiated by a node client can obtain the corresponding nodes for each block after receiving the cluster map from the Monitor, and directly interact with each node to obtain data, eliminating the need for additional data processing layers. Nodes within the group can use block data stored on other nodes within the same group as if it were their own stored data. The Monitor component monitors the status of cluster nodes by maintaining a cluster map. The cluster map records the configuration information and node maps of nodes within the group. The Monitor itself does not directly interact with the Client for data storage; it only provides the service of updating the entire cluster map. The master node's allocation of blocks to other nodes within the group involves two mappings. This two-layer mapping mechanism achieves load balancing during data storage and ensures the important characteristics of the storage architecture, such as decentralization and disaster recovery isolation.

[0089] This invention employs a two-level mapping strategy to address some of the problems associated with consistent hashing ring schemes. Furthermore, by introducing a placement group (PG) through two mappings, the efficiency of data migration during dynamic node joining and leaving can be improved. The PG enables better management of block files, and the weighted data allocation algorithm makes more rational use of node storage capacity.

[0090] Due to the large number of blocks within the entire consortium blockchain, a Placement Group (PG) is introduced to perform the initial mapping of blocks in order to manage these storage objects more evenly and efficiently and achieve better load balancing. A PG is a collection of block objects mapped using a hash algorithm based on the block's sequential number. After being managed by PGs, the mapping map no longer needs to record the correspondence between each block and each node, as this would consume a significant amount of memory due to the sheer number of blocks. Instead, the mapping map only needs to record the mapping relationship between PGs and nodes. By using the PG number corresponding to a block, the corresponding node can be found, greatly reducing the size of the mapping table. Furthermore, the number of PGs is fixed and does not change dynamically with the number of nodes. Therefore, the mapping from block to PG is stable. By directly recording the PG number corresponding to a block in the block header information, the correspondence between the block and PG can be directly obtained, making the block access process more efficient.

[0091] Preferably, during the first mapping process, the setting of the number of PGs (Generic Groups) directly affects the balance of data distribution and the efficiency of data migration when groups change dynamically. Experimental analysis suggests that a reasonable size for the number of PG groups is approximately (number of nodes × 100) / number of ledger files.

[0092] In the above embodiments, preferably, the second mapping involves rationally mapping blocks within the PG to various nodes from the placement group using a load balancing algorithm. Because a multi-replica strategy is employed, mapping blocks within the PG to specific nodes requires multiple calculations during the load balancing algorithm process of this invention. The purpose is to map the replica ledger files and the primary ledger file together to the storage units of different nodes. This two mapping processes ensure load balancing of data within the cluster and disaster recovery isolation between different replicas. For ledger security considerations, this invention adopts a classic three-replica strategy. Even if a single node deletes all its block ledger files, it will not cause the group ledger to be lost. The entire group shares multiple ledger replicas, reducing the storage pressure on individual nodes and addressing the problem of accidental damage or loss of some ledger data.

[0093] The load balancing algorithm of this invention is a weighted hash data distribution algorithm, where the probability of selecting each target node is relatively independent. To achieve more reasonable load balancing and fully utilize the storage performance of nodes within the group, the storage performance of nodes within the group is first classified, with the primary indicator being the node's storage capacity. Nodes with significantly different storage performance are then classified and assigned different weights. If the differences in storage performance are not significant, all nodes in the group are assigned the same weight. This node weight information is recorded in the cluster map of the Monitor component.

[0094] Based on the PG number, node ID, number of secondary ledger files r, and node weight obtained from the first mapping, a weighted random number straw value for each node is calculated using a pseudo-random hash function:

[0095] straw=jenkins hash(PGID,PID,i)*P_weight

[0096] Where Jenkins hash is the pseudo-random number generation function, PGID is the placement group PG number, PID is the node ID, and P_weight is the weight of the current node;

[0097] After each calculation, the pseudo-random hash function is executed again after i+1, until r+1 calculations are performed based on the number of secondary ledger files, so that the primary ledger file and all secondary ledger files can find the corresponding node based on the calculated straw value.

[0098] In the above implementation, preferably, the node with the largest straw value obtained in the first calculation is selected as the storage node of the main ledger file of the block in the PG group;

[0099] Based on the node with the largest straw value obtained in the next calculation that is different from the previous one, store one of the secondary ledger files into that node, until all the secondary ledger files are stored into different nodes in sequence.

[0100] Specifically, since it's a pseudo-random algorithm, the same input parameters yield the same result. This random number is then multiplied by the node's weight to obtain a weighted random number, `straw`. This mapping calculation is performed on all nodes within the group and the PG, and the node with the largest `straw` value is selected as the storage node for the block's main file within that PG group. Next, replica file selection is performed. `r+1` is incremented, and `straw` is calculated again. If the node corresponding to the largest `straw` value is different from the previous node, the replica is placed on that node. `r+1` is incremented again, and `straw` is calculated again, until the node positions for all replicas are found based on the number of replicas. According to this strategy, once the sample size is large enough, this random number no longer affects the selection result; the decisive factor is the node's weight. In other words, the larger the node's weight, the higher the probability of it being selected from a macroscopic perspective.

[0101] The algorithm for the second mapping shows that blocks within the same PG will all be mapped to the same node, while their replicas will be mapped to all other nodes except that node. Furthermore, when there are no changes in the group's nodes, the mapping from PG to node is fixed, and the second mapping process does not need to be performed every time a block is stored. When a node leaves or crashes, the group will remove the node information from the list and redistribute the blocks stored on that node evenly to other nodes using a load balancing algorithm. At this point, because PG objects are set up, a small number of PG objects contain a large number of block objects. Managing a large number of block files within a PG only requires managing PG objects, greatly improving the efficiency of data migration when nodes are unstable.

[0102] like Figure 5 As shown, in the above implementation, preferably, the node collaborative storage method for consortium blockchain ledger data further includes: when a node leaves the consortium blockchain group, querying the PG corresponding to the node, and deleting the node information of the node from the cluster map provided by the cluster monitor;

[0103] Recalculate the straw value of the PG corresponding to the current node on other nodes, map the PG to the node with the largest straw value, and transfer the blocks in the PG to the corresponding node.

[0104] like Figure 6 As shown, in the above embodiments, preferably, the node collaborative storage method for consortium blockchain ledger data further includes:

[0105] When a new node joins the consortium blockchain group, the cluster map registers the node information of the new node;

[0106] According to the algorithm strategy, the straw value of each PG to the newly added node will be recalculated independently. The straw value of each PG will be compared with that of the currently selected node, and some data will be migrated to the new node. Specifically, the straw value of each PG to the new node will be calculated. If the straw value of each PG to the new node is greater than the straw value of its current corresponding node, the blocks in the corresponding PG will be transferred to the new node; otherwise, no transfer is required.

[0107] like Figure 7 As shown, in the above embodiments, preferably, the node collaborative storage method for consortium blockchain ledger data further includes:

[0108] When a transaction query command is received, the node enters the local cache pool to search. If the cache is hit, the transaction result is returned directly. If the cache is not hit, the block information is queried to obtain the PG number corresponding to the block. The node corresponding to the PG number is found through the cluster map, and the node is entered to search for the corresponding block content.

[0109] The local cache pool sets time thresholds and access count thresholds through a cache replacement algorithm. Cache content that is not hit within the time threshold is removed from the local cache pool. When new block content is accessed, it replaces the cache content in the local cache pool that has been accessed less than the access count threshold.

[0110] Specifically, all nodes within the group have a local cache pool. Due to the immutability of the blockchain ledger, there is no consistency issue between the cache and the backend storage. Because the cache pool size is limited, replacement contention inevitably occurs when the cache pool is full. This invention uses an improved cache replacement algorithm that sets both a time threshold and a access count. For example, 72 hours. Any cached content that has not been hit within the 72-hour threshold is directly removed from the cache. Simultaneously, an access count is set, and the access counts are sorted. When new block content is retrieved from the backend, the block with the lowest access count is checked. If the access count is less than 3, the cached block is replaced.

[0111] like Figure 8 As shown, this invention also proposes a node collaborative storage system for consortium blockchain ledger data, applying the node collaborative storage method for consortium blockchain ledger data disclosed in any of the above embodiments, including:

[0112] Group node architecture module 1 is used to calculate the performance of nodes within the consortium blockchain group and sort the nodes according to their performance strength. The nodes with the highest performance ranking are rotated to become the master nodes.

[0113] Local transaction submission module 2 is used to collect and package transactions generated within the consortium blockchain group and submit them to the consensus network of the entire network;

[0114] In the first group mapping module 3, the master node synchronously obtains new blocks from the entire network and determines the corresponding placement group (PG) of the block through the first mapping based on the hash data of the block number.

[0115] The weight random calculation module 4 is used to perform r+1 random number calculations on the PG number, node ID and the number of secondary ledger files r using a pseudo-random hash algorithm, and to calculate the random number straw value of the corresponding node based on the weight of each node in the consortium chain group.

[0116] The secondary equalization mapping module 5 is used to map and store the main ledger file and r secondary ledger files of the block to the different nodes with the largest straw value obtained in each calculation for the second time.

[0117] The node collaborative storage system for consortium blockchain ledger data disclosed in the above embodiments has the same functions as the steps in the node collaborative storage method for consortium blockchain ledger data disclosed in the above embodiments. For specific implementation process, please refer to the above method, which will not be repeated here.

[0118] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A node collaborative storage method for consortium blockchain ledger data, characterized in that, include: For nodes within a consortium blockchain group, the performance of the nodes is calculated and the nodes are ranked according to their performance strength. A preset proportion of nodes with the highest performance ranking are rotated to become the master nodes. The master node collects and packages the transactions generated within the consortium blockchain group and submits them to the consensus network of the entire network; The master node synchronously obtains new blocks from the entire network, and determines the corresponding placement group (PG) for each block through a first mapping based on the hash data of the block number. The specific process includes: A hash value is obtained by performing a hash calculation on the block height of the block to be allocated. The hash value is then moduloed by the number of PGs to obtain the PG corresponding to the block. Here, PG is a set of block objects mapped by the above hash algorithm, and the number of PGs is preset according to the number of secondary ledger files based on the number of nodes. The pseudo-random hash algorithm is used to perform r+1 random number calculations on the PG number, node ID, and number of secondary ledger files r, and the random number straw value of the corresponding node is calculated based on the weight of each node in the consortium chain group. The main ledger file and r secondary ledger files of the block are mapped and stored for the second time to the different nodes with the largest straw values ​​obtained in each calculation.

2. The node collaborative storage method for consortium blockchain ledger data according to claim 1, characterized in that, Also includes: When a node leaves the consortium blockchain group, the PG corresponding to that node is queried, and the node information of that node is deleted from the cluster map provided by the cluster monitor. Recalculate the straw value of the PG corresponding to the current node on other nodes, map the PG to the node with the largest straw value, and transfer the blocks in the PG to the corresponding node.

3. The node collaborative storage method for consortium blockchain ledger data according to claim 1 or 2, characterized in that, Also includes: When a new node joins the consortium blockchain group, the cluster map registers the node information of the new node; Calculate the straw value of each PG to the new node. If the straw value of each PG to the new node is greater than the straw value of its current corresponding node, then the blocks in the corresponding PG are transferred to the new node; otherwise, no transfer is required.

4. The node collaborative storage method for consortium blockchain ledger data according to claim 3, characterized in that, The specific method for determining the performance of the computing nodes and ranking them according to performance, with a predetermined proportion of the nodes ranked highest in performance being used as master nodes in a round-robin fashion, includes: The standardized node parameters of the node are calculated using the following standardized calculation formula: Where Ti is the standardized node parameter, T r For standardized node parameters, T min The minimum value of the same parameter in the consortium blockchain group. This is the average value of all parameters; The performance value of the node is calculated using the following formula, based on the node's storage capacity, CPU parameters, disk I / O rate, memory, and network bandwidth: P i =k1S i +k2C i +k3M i +k4D i +k5W i Among them, P i S represents the performance value of the node, k1…k5 are the weights of each parameter, and S represents the performance value of the node. i For storage capacity, C i D is the product of the number of CPUs and the CPU processing frequency. i For disk I / O speed, M i For memory size, W i For network bandwidth; According to the performance value P i All nodes are sorted from strongest to weakest. Among the nodes with the highest performance, the first-ranked node becomes the master node, and after each round of block production, the next-ranked node becomes the master node. If a node crashes while serving as the master node, the next-ranked node will immediately take over as the master node. The crashed node will not participate in the master node rotation process for a preset time threshold. After the preset time threshold is exceeded, the nodes in the current consortium chain group will vote to determine whether the current node can participate in the master node rotation.

5. The node collaborative storage method for consortium blockchain ledger data according to claim 4, characterized in that, The specific process by which the master node collects, packages, and submits transactions generated within the consortium blockchain group to the consensus network of the entire network includes: The master node listens to all transactions initiated by all nodes in the current consortium blockchain group, collects the listened transactions, packages them into a transaction set, and submits them to the main chain of the consortium blockchain at a preset frequency. After reaching a consensus across the entire network, a new block is generated and distributed to the corresponding nodes of each consortium blockchain for storage based on the information in the new block.

6. The node collaborative storage method for consortium blockchain ledger data according to claim 1, characterized in that, The specific process of using a pseudo-random hash algorithm to perform r+1 random number calculations on the PG number, node ID, and the number r of secondary ledger files, and calculating the corresponding node's straw value based on the weight of each node in the consortium blockchain group includes: Based on the PG number, node ID, number of secondary ledger files r, and node weight, a weighted random number straw value is calculated for each node using a pseudo-random hash function: straw=jenkins hash(PGID,PID,i)*P_weight Where Jenkins hash is the pseudo-random number generation function, PGID is the placement group PG number, PID is the node ID, and P_weight is the weight of the current node; After each calculation, the pseudo-random hash function is executed again after i+1, until r+1 calculations are performed based on the number of secondary ledger files, so that the primary ledger file and all secondary ledger files can find the corresponding node based on the calculated straw value.

7. The node collaborative storage method for consortium blockchain ledger data according to claim 6, characterized in that, The specific process of mapping and storing the main ledger file and r secondary ledger files of the block to the different nodes with the largest straw values ​​obtained in each calculation for the second time includes: Select the node with the largest straw value obtained in the first calculation as the storage node for the main ledger file of the block in that PG group; Based on the node with the largest straw value obtained in the next calculation that is different from the previous one, store one of the secondary ledger files into that node, until all the secondary ledger files are stored into different nodes in sequence.

8. The node collaborative storage method for consortium blockchain ledger data according to claim 7, characterized in that, Also includes: Upon receiving a transaction query instruction, the node enters the local cache pool to search. If the cache is hit, the transaction result is returned directly. If the cache is not hit, the node queries the block information to obtain the PG number corresponding to the block, finds the node corresponding to the PG number through the cluster map, and enters the node to search for the corresponding block content. The local cache pool sets a time threshold and an access count threshold through a cache replacement algorithm. Cache content that is not hit within the time threshold is removed from the local cache pool. When new block content is accessed, it replaces the cache content in the local cache pool that has been accessed less than the access count threshold.

9. A node collaborative storage system for consortium blockchain ledger data, characterized in that, The node collaborative storage method for consortium blockchain ledger data as described in any one of claims 1 to 8 includes: The group node architecture module is used to calculate the performance of nodes within a consortium blockchain group and sort the nodes by performance strength. The nodes with the highest performance ranking are rotated to become the master nodes. The local transaction submission module is used to collect and package transactions generated within the consortium blockchain group and submit them to the consensus network of the entire network. In the first group mapping module, the master node synchronously obtains new blocks from the entire network and determines the corresponding placement group (PG) of the block through the first mapping based on the hash data of the block number. The weight random calculation module is used to perform r+1 random number calculations on the PG number, node ID and the number r of secondary ledger files using a pseudo-random hash algorithm, and to calculate the random number straw value of the corresponding node based on the weight of each node in the consortium chain group. The secondary balanced mapping module is used to map and store the main ledger file and r secondary ledger files of the block to the different nodes with the largest straw values ​​obtained in each calculation for the second time. The specific process by which the primary grouping mapping module obtains the placement group PG includes: A hash value is obtained by performing a hash calculation on the block height of the block to be allocated. The hash value is then moduloed by the number of PGs to obtain the PG corresponding to the block. Here, PG is a set of block objects mapped by the above hash algorithm, and the number of PGs is preset according to the number of secondary ledger files based on the number of nodes.

Images