Digital bond alliance chain dynamic partition consensus method, device, medium and equipment

Abstract

The present application discloses a dynamic partitioning consensus method, device, medium and equipment for a digital bond alliance chain, which relates to the field of blockchain technology. The method includes: partitioning the business of a tree-like hierarchical digital bond alliance chain network to obtain business partitions of different bond network layers; using a preset heuristic distributed hash table algorithm to partition and store the business data in the bottom business partition and the middle business partition respectively; using a preset secret sharing algorithm to partition and store the business data in the top business partition; for any business partition in the business partitions of different bond network layers, according to the business attributes of the participants in any business partition, determining the decision weight of the main consensus node of the participant in any business partition, so that the participant can participate in consensus decision-making in any business partition based on the decision weight. The present application can improve the efficiency of consensus decision-making and reduce the data storage pressure of the node.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a method, device, medium, and equipment for dynamic partitioning consensus of a digital bond alliance chain. Background Art

[0002] Blockchain technology has become a hot topic and is gradually being applied to the financial bond sector. An increasing number of businesses and governments are investing in the research and development and implementation of blockchain technology, driving its continued development and improvement.

[0003] The blockchain was initially designed with the idea that each node would have the same functions and rights, and all business data would be stored on the same node. However, if all nodes had the same rights, consensus decision-making efficiency would be low, and if all data were stored on the same node, it would place significant pressure on the node's data storage. Summary of the Invention

[0004] In view of this, the present application provides a digital bond alliance chain dynamic partition consensus method, device, medium and equipment, the main purpose of which is to solve the problem of equal authority in the consensus process, improve the efficiency of consensus decision-making, and reduce the data storage pressure of nodes.

[0005] According to the first aspect of the present application, a digital bond consortium chain dynamic partition consensus method is provided, the method comprising:

[0006] Performing business partitioning on the tree-like hierarchical digital bond alliance chain network to obtain business partitions of different bond network layers, wherein the business partitions of different bond network layers include top-layer business partitions, middle-layer business partitions, and bottom-layer business partitions;

[0007] Using a preset heuristic distributed hash table algorithm to separately store the business data in the bottom business partition and the middle business partition;

[0008] Using a preset secret sharing algorithm to segment and store the business data in the top-level business partition;

[0009] For any one of the business partitions of the different bond network layers, the decision weight of the main consensus node of the participant in any one of the business partitions is determined according to the business attributes of the participants in the any one of the business partitions, so that the participants can participate in consensus decision-making in the any one of the business partitions based on the decision weight.

[0010] According to the second aspect of the present application, a digital bond consortium chain dynamic partition consensus device is provided, the device comprising:

[0011] A partitioning unit is used to partition the tree-like hierarchical digital bond alliance chain network into business partitions to obtain business partitions of different bond network layers, wherein the business partitions of different bond network layers include top-level business partitions, middle-level business partitions, and bottom-level business partitions;

[0012] A first storage unit is configured to separately store the service data in the bottom service partition and the middle service partition using a preset heuristic distributed hash table algorithm;

[0013] A second storage unit is used to divide and store the business data in the top-level business partition using a preset secret sharing algorithm;

[0014] A decision-making unit is used to determine, for any one of the business partitions of the different bond network layers, the decision weight of the main consensus node of the participant in the any one business partition according to the business attributes of the participants in the any one business partition, so that the participant participates in the consensus decision in the any one business partition based on the decision weight.

[0015] According to the third aspect of the present application, a storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the above-mentioned digital bond alliance chain dynamic partition consensus method is implemented.

[0016] According to the fourth aspect of the present application, an electronic device is provided, comprising a storage medium, a processor, and a computer program stored on the storage medium and runnable on the processor, wherein when the processor executes the program, the dynamic partitioning consensus method of the digital bond alliance chain is implemented.

[0017] By leveraging the above technical solution, this application provides a dynamic partitioning consensus method, device, medium, and equipment for a digital bond consortium chain. Compared to the prior art, this application partitions the tree-like hierarchical digital bond consortium chain network into business zones and configures the decision weights of the main consensus nodes based on the business attributes of the participants in the business zones. This solves the problem of equal authority in the blockchain consensus process, thereby improving the efficiency of consensus decision-making. At the same time, this application reduces the data storage pressure of the nodes by segmenting and storing the record data of the accounting nodes within the business zones.

[0018] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0020] Figure 1 A schematic diagram of a process for a dynamic partitioning consensus method for a digital bond consortium chain provided in an embodiment of the present application is shown;

[0021] Figure 2 A schematic diagram of the tree-like hierarchical digital bond alliance chain network architecture provided in an embodiment of the present application is shown;

[0022] Figure 3 A schematic diagram of the structure of a dynamic partition consensus device for a digital bond alliance chain provided in an embodiment of the present application is shown;

[0023] Figure 4 A structural diagram of another digital bond alliance chain dynamic partition consensus device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that, unless there is a conflict, the embodiments and features in the embodiments of the present application can be combined with each other.

[0025] In the existing technology, all nodes have the same rights, resulting in low efficiency of consensus decision-making. In addition, all data in the existing technology is stored in the same node, causing great pressure on the node's data storage.

[0026] In order to solve the above problems, the embodiment of the present invention provides a digital bond alliance chain dynamic partition consensus method, such as Figure 1 As shown, the method includes:

[0027] Step 10: Perform business partitioning on the tree-like hierarchical digital bond alliance chain network to obtain business partitions at different bond network layers.

[0028] Among them, the business partitions of the different bond network layers include top-level business partitions, middle-level business partitions and bottom-level business partitions, and each of the above business partitions includes a main consensus node, a backup consensus node and an accounting node.

[0029] In order to solve the problems of equal authority, consensus efficiency bottleneck and data storage burden in the blockchain consensus process, the embodiment of the present invention proposes a tree-like hierarchical digital bond alliance chain network architecture, such as Figure 2 As shown, it includes a top-layer network, a middle-layer network and a bottom-layer network, and the top-layer network, the middle-layer network and the bottom-layer network are partitioned into service zones to obtain top-layer service zones, middle-layer service zones and bottom-layer service zones.

[0030] The bottom-level business partition consists of bond investors' equipment, the middle-level business partition consists of bond bookkeepers and issuers, and the top-level business partition consists of central securities depositories and regulatory agencies. The bottom-level business partitions are divided according to bond business, and each business partition maintains a complete copy of bond business data. The data is sharded and stored across different accounting nodes in each business partition to ensure that the data in that business partition can be recovered by a certain number of accounting nodes, thereby preventing accounting node failures or data tampering. In addition, the bottom-level business partitions can be expanded horizontally, that is, multiple business partitions can be established at the bottom level for different types of bonds (such as government bonds, corporate bonds, financial bonds, government bonds, etc.). The data between each application chain is naturally isolated, and different types of bond partitions can be further expanded into sub-partitions based on the number of bonds issued.

[0031] The middle-tier business partition maintains the bond business data of the lower-tier management partition (the underlying business partition) and is responsible for interacting with the bond business data of the underlying business partition. For example, when a bond changes from registration status to custody status, the custody business partition needs to obtain the business data of the registration partition through the middle-tier business partition and is responsible for forwarding different transaction proposal requests to the consensus nodes in the corresponding underlying partition.

[0032] The top-level business partition maintains all bond business data, is responsible for the bond business data interaction of the middle-level business partition, and is responsible for forwarding different transaction proposal requests to the corresponding middle-level partition nodes.

[0033] In addition, the number of top-level business partitions is one, and the number of middle-level business partitions and bottom-level business partitions is at least two. Each of the above business partitions has a primary consensus node, a backup consensus node, and an accounting node.

[0034] Step 20: Use a preset heuristic distributed hash table algorithm to separately store the business data in the bottom-layer business partition and the middle-layer business partition.

[0035] In the embodiment of the present invention, for the underlying business partitions and the middle-layer business partitions, a preset heuristic distributed hash table algorithm is used to divide the business data and store them in different accounting nodes, thereby preventing accounting node failure or data tampering.

[0036] For the process of data segmentation using a preset heuristic distributed hash table algorithm, the method includes: counting the call frequency of each data in the business data of the underlying business partition and the intermediate business partition within a preset time length; calculating the first redundancy corresponding to each data according to the call frequency, and the data fault tolerance coefficient and the total number of accounting nodes corresponding to the underlying business partition and the intermediate business partition respectively; based on the first redundancy, determining whether the number of accounting nodes of the business to which each data belongs meets the redundancy requirement; if the number of accounting nodes of the business to which the data belongs does not meet the redundancy requirement, using a preset hash function to calculate the keyword corresponding to each data, based on the keyword and the identifiers of the existing accounting nodes in the underlying business partition and the intermediate business partition, from the existing The accounting node matches a related target accounting node for each piece of data; based on the first redundancy, determines whether the number of accounting nodes of the business owner and the number of related target accounting nodes meet the redundancy requirements; if the number of accounting nodes of the business owner and the number of related target accounting nodes do not meet the redundancy requirements, elastically expand the first accounting node based on the first redundancy, the number of accounting nodes of the business owner, and the number of target accounting nodes; stores each piece of data in the accounting node of the business owner, the target accounting node, and the elastically expanded first accounting node respectively, and stores the identifier of the accounting node of the business owner, the identifier of the target accounting node, and the identifier of the first accounting node in the upper-layer business partition corresponding to the bottom-layer business partition and the middle-layer business partition respectively.

[0037] The preset duration can be set based on actual business needs and is not specifically limited in this embodiment of the present invention. For example, the preset duration can be set to an epoch. Furthermore, the preset hash function can specifically be an SM3 hash function. The identifier of the accounting node can specifically refer to the ID of the accounting node.

[0038] The same data segmentation process is used for both underlying and intermediate business partitions. Specifically, the following steps are used: First, the call frequency (SearchTimes) for each piece of data in a given underlying or intermediate business partition within an epoch is calculated, where SearchTimes = total(epoch, data). The first redundancy (share) of each piece of data is then calculated, where share = SearchTimes / n × s, where s is the adjustable data fault tolerance factor and n is the total number of accounting nodes in the partition. The corresponding accounting node is then selected for each piece of business data.

[0039] When selecting an accounting node, first determine whether the number of accounting nodes of the business owner (such as an investor) corresponding to each piece of data meets the redundancy requirements. If the redundancy requirements are met, the data is directly stored in the accounting node to which the business belongs. If the redundancy requirements are not met, a hash calculation is required. For example, if the first redundancy is 5 and the number of accounting nodes of the business owner is only 1, it means that the number of accounting nodes of the business owner does not meet the redundancy requirements. At this time, the data data is input into the SM3 hash function to calculate its summary, and the calculated summary is used as the keyword key of the data data, that is, key = SM3 (data). Then, the relevant target accounting node is matched based on the keyword key of the data data according to the identifier of the existing accounting node. The matching rule is id mod n == key mod n. If the number of accounting nodes of the business owner and the number of target accounting nodes meet the redundancy requirements, the data data is stored in the accounting node of the business owner and the target accounting node respectively, and there is no need to elastically expand the accounting nodes; if the number of accounting nodes of the business owner and the target accounting node still do not meet the redundancy requirements, the first redundancy is subtracted from the number of accounting nodes of the business owner and the target accounting node to obtain the number of first accounting nodes that need to be elastically expanded. For example, if the first redundancy is 5, the number of accounting nodes of the business owner is 1, and the number of target accounting nodes is 2, the number of first accounting nodes that need to be elastically expanded is 5-1-2=2. Finally, the data data is stored in the accounting node of the business owner, the target accounting node, and the first accounting node respectively, and the identifier of the accounting node of the business owner, the identifier of the target accounting node, and the identifier of the first accounting node are stored in the upper-level business partition.

[0040] Furthermore, when performing business data retrieval, i.e., data recovery, the upper-level business partition is queried to obtain the identifier of the accounting node of the business owner, the identifier of the target accounting node, and the identifier of the first accounting node; based on the identifier of the accounting node of the business owner, the accounting node of the business owner is queried to read the data; if the accounting node of the business owner fails, the target accounting node is queried to read the data based on the identifier of the target accounting node; if the target accounting node fails, the first accounting node is queried to read the data based on the identifier of the first accounting node.

[0041] Specifically, the data storage accounting node identifier is obtained from the upper-level business partition, specifically including the identifier of the business owner's accounting node, the identifier of the target accounting node, and the identifier of the first accounting node. The business owner's accounting node is then retrieved. If the business owner's accounting node is not faulty, the data is read from the business owner's accounting node. If the business owner's accounting node is faulty, the target accounting node determined by the hash value is retrieved. If the target accounting node is not faulty, the data is read from the target accounting node. If the target accounting node is faulty, the elastically expanded first accounting node is retrieved and the data is read from the first accounting node.

[0042] The embodiment of the present invention can partition, store and restore data in the bottom layer business partition and the middle layer business partition by adopting an inspired distributed hash table algorithm.

[0043] Step 30: Use a preset secret sharing algorithm to segment and store the business data in the top-level business partition.

[0044] The preset secret sharing algorithm may be the Shamir algorithm.

[0045] In the embodiment of the present invention, for the top-level business partition, the Shamir algorithm is used to divide the business data and store it in different accounting nodes, thereby preventing accounting node failure or data tampering.

[0046] Regarding the process of data segmentation using the Shamir algorithm, the method includes: obtaining the second redundancy pre-configured for the top-level business partition and the number of accounting nodes of the top-level business partition; if the number of accounting nodes of the top-level business partition does not meet the redundancy requirement, elastically expanding the second accounting node based on the second redundancy and the number of accounting nodes of the top-level business partition; numbering the accounting nodes of the top-level business partition and the elastically expanded second accounting nodes; uniformly dividing the target block where the business data in the top-level business partition is located to obtain multiple partition blocks; randomly generating a polynomial according to the second redundancy; based on the index value corresponding to the target block and the polynomial, storing the business data of each of the multiple partition blocks in the corresponding numbered accounting node; storing the index value corresponding to the target block and the coefficient of the polynomial in a configuration block, wherein the configuration block does not participate in the segmentation and is stored in the corresponding accounting node.

[0047] The target block is any block in the top-level business partition.

[0048] Specifically, obtain the second redundancy k preset for the top-level service partition and the number n of bookkeeping nodes in the top-level service partition. If k ≤ n, it means that the number of bookkeeping nodes in the top-level service partition meets the redundancy requirement and there is no need to elastically expand the bookkeeping nodes. If k < n, it means that the number of bookkeeping nodes in the top-level service partition does not meet the redundancy requirement, then expand k - n second bookkeeping nodes, and number the bookkeeping nodes in the top-level service partition and the elastically expanded second bookkeeping nodes. Then evenly divide the target block with index h to obtain n divided blocks. Next, according to the second redundancy, randomly generate the polynomial f(x) = a0 + a1x + a2x 2 +…+akx k . For the target block with index value h, calculate f(h), use f(h) as the blockchain retrieval keyword, and store the i-th divided block of the target block in the bookkeeping nodes numbered f(h) + i + 1 mod n, f(h) + i + 2 mod n,..., f(h) + i + k mod n respectively. In this way, each divided block can be stored in the corresponding numbered bookkeeping node according to the above method. At the same time, store the index value h of the target block and the polynomial system in the configuration block, and this configuration block does not participate in the division and is stored in each bookkeeping node.

[0049] Furthermore, when performing business data retrieval, that is, data recovery, read the index value corresponding to the target block and the coefficients of the polynomial from the configuration block; based on the coefficients of the polynomial, restore the polynomial, and substitute the index value corresponding to the target block into the polynomial for calculation to obtain the retrieval keyword; based on the retrieval keyword, determine the numbers of the bookkeeping nodes where each divided block is stored; according to the numbers of the bookkeeping nodes where each divided block is stored, find each divided block from any available bookkeeping node; perform data recovery based on the found each divided block to obtain the target block.

[0050] Specifically, for the data recovery of the target block with index value h, first read the index value h and the polynomial coefficients a0, a1,..., ak from the configuration block, restore the polynomial f(x), and calculate f(h). Then find the data of the i-th divided block of the target block in any available bookkeeping node in {f(h) + i + 1 mod n, f(h) + i + 2 mod n,..., f(h) + i + k mod n}. Collecting the data of k divided blocks can restore the target block.

[0051] The embodiment of the present invention can perform segmented storage and recovery of data in the top-level service partition by adopting the Shamir algorithm.

[0052] Step 40: For any one of the business partitions of the different bond network layers, determine the decision weight of the main consensus node of the participant in any one of the business partitions based on the business attributes of the participants in the any one of the business partitions, so that the participants can participate in consensus decision-making in the any one of the business partitions based on the decision weight.

[0053] Among them, any business partition is Figure 2 In the network architecture shown, any service partition can be a top-level service partition, a middle-level service partition, or a bottom-level service partition.

[0054] In an embodiment of the present invention, when any business partition is an underlying business partition, the participating party is an investor, and the investor's business attributes include the investor's bid price and bid quantity. In this case, the decision weight of the investor's primary consensus node in the underlying business partition can be determined based on the investor's bid price and bid quantity in the underlying business partition, so that the investor participates in consensus decision-making in the underlying business partition based on the decision weight. The higher the bid price and the greater the bid quantity, the higher the decision weight of the primary consensus node. Conversely, the lower the bid price and the smaller the bid quantity, the lower the decision weight of the primary consensus node.

[0055] For example, in the underlying Treasury Bond 001 business partition, the decision weight of investor A's main consensus node is 70%, the decision weight of investor B's main consensus node is 20%, and the decision weight of investor C's main consensus node is 10%.

[0056] Furthermore, the embodiment of the present invention can also determine the decision weights of the participants in different business partitions according to the business roles of the participants in different business partitions, so that the participants can make decisions in different business partitions based on the decision weights.

[0057] For example, based on investor A's business roles in the Treasury Bond 001 business partition and the Financial Bond 098 business partition, the investor's decision weights in the Treasury Bond 001 business partition and the Financial Bond 098 business partition are determined. Based on different decision weights, investor A participates in the decision-making of the Treasury Bond 001 business partition and the Financial Bond 098 business partition respectively.

[0058] Furthermore, embodiments of the present invention can also upgrade or downgrade backup consensus nodes. For this process, the method includes: if the system real-time requirement does not exceed the preset real-time requirement, and the load of the main consensus node is less than the preset load, setting a main consensus node, and when the main consensus node fails, directly upgrading the backup consensus node to the main consensus node; if the system real-time requirement exceeds the preset real-time requirement, or the load of the main consensus node is greater than or equal to the preset load, setting at least two main consensus nodes, and selecting one of the at least two main consensus nodes to participate in consensus decision-making; when the number of nodes of the at least two main consensus nodes is less than the preset number of nodes, upgrading the backup consensus node to the main consensus node; when the number of nodes of the at least two main consensus nodes is greater than or equal to the preset number of nodes, downgrading some of the at least two main consensus nodes to backup consensus nodes.

[0059] The preset number of nodes and the preset real-time requirement may be set according to actual business needs, and the embodiment of the present invention does not impose any specific limitation on this.

[0060] Specifically, if the system real-time requirements are not high and the load of the main consensus node is relatively low, then only one main consensus node can be set in the business partition. Since the system real-time requirements are not high and the load of the main consensus node is relatively low, at this time, once the main consensus node fails, the backup consensus node can be directly upgraded to the main consensus node; if the system real-time requirements are high, or the load of the main consensus node is relatively large, then at least two main consensus nodes need to be set, because it takes a certain amount of time for the backup consensus node to be upgraded to the main consensus node to participate in the consensus. Therefore, when the system real-time requirements are relatively high or the load of the main consensus node is relatively large, upgrading the backup consensus node is likely to cause system delays. Therefore, at least two consensus nodes need to be set. When the main consensus node participating in the consensus fails, other main consensus nodes can be used directly without pulling up the backup consensus node.

[0061] In specific application scenarios, when the load on the main consensus node is relatively low, the backup consensus node can directly pull the ledger and decision data for data preparation. When the main consensus node fails subsequently, the backup consensus node can be upgraded to the main consensus node because the backup consensus node has completed data preparation.

[0062] When the system has high real-time requirements or the load on the master consensus node is relatively large, it is necessary to maintain the number of master consensus nodes at a certain value. When the number of master consensus nodes is less than the preset number of nodes, the backup consensus node is upgraded to the master consensus node; when the number of master consensus nodes is greater than or equal to the preset number of nodes, the master consensus node can be downgraded to a backup consensus node.

[0063] Furthermore, the number of accounting nodes within each business partition will increase as the business grows. Since completed bond transactions have a low correlation with subsequent new bond transactions, the historical data of completed bond transactions can be cleaned up to reduce the storage burden on the relevant accounting nodes. Specifically, bonds that have been issued, registered, held in custody, traded, and settled can be retrieved by bond code. After that, the nodes of the top-level business partition will broadcast a deletion proposal to the entire network. The accounting nodes of each business partition will delete the relevant business data based on the bond code to complete the processing of the deletion proposal.

[0064] The dynamic partitioning consensus method for a digital bond consortium chain provided by the present invention addresses the issue of equal authority during the blockchain consensus process by partitioning the tree-like hierarchical digital bond consortium chain network into business zones and configuring the decision weights of the master consensus node based on the business attributes of the participants in the business zones, thereby improving the efficiency of consensus decision-making. Furthermore, by segmenting and storing the recorded data of accounting nodes within the business zones, the present invention reduces the data storage pressure on the nodes.

[0065] Further, as Figure 1 The specific implementation of the method shown in this embodiment provides a digital bond alliance chain dynamic partition consensus device, such as Figure 3 As shown, the device includes: a partitioning unit 101, a first storage unit 102, a second storage unit 103 and a decision unit 104.

[0066] The partitioning unit 101 can be used to partition the business of the tree-like hierarchical digital bond alliance chain network to obtain business partitions of different bond network layers, wherein the business partitions of different bond network layers include top-level business partitions, middle-level business partitions, and bottom-level business partitions.

[0067] The first storage unit 102 may be configured to separately store the business data in the bottom-layer business partition and the middle-layer business partition using a preset heuristic distributed hash table algorithm.

[0068] The second storage unit 103 may be configured to segment and store the service data in the top-level service partition using a preset secret sharing algorithm.

[0069] The decision unit 104 can be used to determine the decision weight of the main consensus node of the participant in any business partition of the business partitions of the different bond network layers according to the business attributes of the participants in any business partition, so that the participant can participate in consensus decision-making in any business partition based on the decision weight.

[0070] In some embodiments, for any of the service partitions, such as Figure 4 As shown, the device further includes: an upgrading and downgrading unit 105.

[0071] The upgrade and downgrade unit 105 can be used to set a master consensus node if the system real-time requirement does not exceed the preset real-time requirement and the load of the master consensus node is less than the preset load. When the master consensus node fails, the backup consensus node is directly upgraded to the master consensus node; if the system real-time requirement exceeds the preset real-time requirement, or the load of the master consensus node is greater than or equal to the preset load, at least two master consensus nodes are set and one of the at least two master consensus nodes is selected to participate in consensus decision-making; when the number of nodes of the at least two master consensus nodes is less than the preset number of nodes, the backup consensus node is upgraded to the master consensus node; when the number of nodes of the at least two master consensus nodes is greater than or equal to the preset number of nodes, some of the at least two master consensus nodes are downgraded to backup consensus nodes.

[0072] In some embodiments, when any one of the business partitions is the underlying business partition, and the business attributes of the participant include the bid price and bid quantity of the investor, the decision unit 104 can be specifically used to determine the decision weight of the investor's main consensus node in the underlying business partition based on the bid price and bid quantity of the investor in the underlying business partition, so that the investor participates in consensus decision-making in the underlying business partition based on the decision weight.

[0073] In some embodiments, the first storage unit 102 can be specifically used to count the call frequency of each data in the business data of the underlying business partition and the intermediate business partition within a preset time length; calculate the first redundancy corresponding to each data according to the call frequency, and the data fault tolerance coefficient and the total number of accounting nodes corresponding to the underlying business partition and the intermediate business partition respectively; based on the first redundancy, determine whether the number of accounting nodes of the business to which each data belongs meets the redundancy requirement; if the number of accounting nodes of the business to which the data belongs does not meet the redundancy requirement, use a preset hash function to calculate the keyword corresponding to each data, and based on the keyword and the identifiers of the existing accounting nodes in the underlying business partition and the intermediate business partition, select the accounting node from the existing accounting nodes. Match the relevant target accounting node for each data; based on the first redundancy, determine whether the number of accounting nodes of the business owner and the number of relevant target accounting nodes meet the redundancy requirements; if the number of accounting nodes of the business owner and the number of relevant target accounting nodes do not meet the redundancy requirements, elastically expand the first accounting node based on the first redundancy, the number of accounting nodes of the business owner and the number of target accounting nodes; store each data in the accounting node of the business owner, the target accounting node and the elastically expanded first accounting node respectively, and store the identifier of the accounting node of the business owner, the identifier of the target accounting node and the identifier of the first accounting node in the upper-layer business partition corresponding to the bottom-layer business partition and the middle-layer business partition respectively.

[0074] In some embodiments, the apparatus further includes: a recovery unit 106 .

[0075] The recovery unit 106 can be used to query the upper-layer business partition when performing business data retrieval, obtain the identifier of the billing node of the business owner, the identifier of the target billing node, and the identifier of the first billing node; based on the identifier of the billing node of the business owner, query the billing node of the business owner to read data; if the billing node of the business owner fails, query the target billing node according to the identifier of the target billing node to read data; if the target billing node fails, query the first billing node according to the identifier of the first billing node to read data.

[0076] In some embodiments, the second storage unit 103 can be specifically used to obtain the second redundancy pre-configured for the top-level business partition and the number of accounting nodes of the top-level business partition; if the number of accounting nodes of the top-level business partition does not meet the redundancy requirement, elastically expand the second accounting node based on the second redundancy and the number of accounting nodes of the top-level business partition; number the accounting nodes of the top-level business partition and the elastically expanded second accounting nodes; evenly divide the target block where the business data in the top-level business partition is located to obtain multiple partitions; randomly generate a polynomial according to the second redundancy; based on the index value corresponding to the target block and the polynomial, store the business data of each of the multiple partitions in the corresponding numbered accounting nodes respectively; store the index value corresponding to the target block and the coefficient of the polynomial in the configuration block respectively, wherein the configuration block does not participate in the partitioning and is stored in the corresponding accounting node.

[0077] In some embodiments, the recovery unit 106 can also be used to read the index value corresponding to the target block and the coefficient of the polynomial from the configuration block when performing business data retrieval; based on the coefficient of the polynomial, restore the polynomial, and bring the index value corresponding to the target block into the polynomial for calculation to obtain a retrieval keyword; based on the retrieval keyword, determine the number of the accounting node stored in each partition block; according to the number of the accounting node stored in each partition block, search for each partition block from any available accounting node; perform data recovery based on each partition block found to obtain the target block.

[0078] It should be noted that for other corresponding descriptions of the functional units involved in the dynamic partition consensus device of the digital bond alliance chain provided by the embodiment of the present invention, please refer to Figure 1 The corresponding description in will not be repeated here.

[0079] Based on the above Figure 1 The method shown in FIG. 1 is a method for performing the above-mentioned operation. Accordingly, this embodiment further provides a storage medium on which a computer program is stored. When the program is executed by a processor, the above-mentioned Figure 1 The dynamic partitioning consensus method of the digital bond alliance chain shown.

[0080] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling an electronic device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0081] Based on the above Figure 1 The method shown, and Figure 3 and Figure 4 In order to achieve the above-mentioned purpose, the embodiment of the present application further provides an electronic device, which can be a personal computer, a tablet computer, a server, or other network equipment, etc. The device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 The dynamic partitioning consensus method of the digital bond alliance chain shown.

[0082] Optionally, the physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, and the like. The user interface may include a display, an input unit such as a keyboard, and the like. The optional user interface may also include a USB interface, a card reader interface, and the like. The network interface may optionally include a standard wired interface, a wireless interface (such as a Wi-Fi interface), and the like.

[0083] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0084] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.

[0085] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform, or by hardware.

[0086] This embodiment of the present invention resolves the issue of equal authority during the blockchain consensus process by partitioning the tree-like hierarchical digital bond consortium chain network into business zones and assigning decision weights to master consensus nodes based on the business attributes of the participants in each zone. This improves the efficiency of consensus decision-making. Furthermore, this embodiment of the present invention reduces node data storage pressure by segmenting and storing the recorded data of accounting nodes within each zone.

[0087] Those skilled in the art will understand that the accompanying drawings are only schematic diagrams of a preferred implementation scenario, and the modules or processes in the accompanying drawings are not necessarily required to implement the present application. Those skilled in the art will understand that the modules in the devices in the implementation scenario can be distributed in the devices of the implementation scenario according to the implementation scenario description, or can be changed accordingly and located in one or more devices different from the implementation scenario. The modules of the above-mentioned implementation scenario can be combined into one module, or can be further split into multiple sub-modules.

[0088] The serial numbers of the above application are for descriptive purposes only and do not represent the advantages or disadvantages of the implementation scenarios. The above disclosure only discloses several specific implementation scenarios of the present application, but the present application is not limited thereto. Any changes that can be conceived by those skilled in the art should fall within the scope of protection of the present application.

Claims

1. A dynamic partition consensus method for a digital bond alliance chain, characterized by: include: Performing business partitioning on the tree-like hierarchical digital bond alliance chain network to obtain business partitions of different bond network layers, wherein the business partitions of different bond network layers include top-layer business partitions, middle-layer business partitions, and bottom-layer business partitions; Using a preset heuristic distributed hash table algorithm to separately store the business data in the bottom business partition and the middle business partition; Using a preset secret sharing algorithm to segment and store the business data in the top-level business partition; For any one of the business partitions of the different bond network layers, determining the decision weight of the participant's primary consensus node in the any one business partition based on the business attributes of the participant in the any one business partition, so that the participant participates in consensus decision-making in the any one business partition based on the decision weight; Wherein, for any one of the service partitions, the method further includes: If the system real-time requirement does not exceed the preset real-time requirement, and the load of the main consensus node is less than the preset load, a main consensus node is set. When the main consensus node fails, the backup consensus node is directly upgraded to the main consensus node; If the system real-time requirement exceeds the preset real-time requirement, or the master consensus node load is greater than or equal to the preset load, at least two master consensus nodes are set, and one of the at least two master consensus nodes is selected to participate in consensus decision-making; When the number of nodes of the at least two main consensus nodes is less than the preset number of nodes, upgrading the backup consensus node to the main consensus node; When the number of nodes of the at least two main consensus nodes is greater than or equal to the preset number of nodes, some of the at least two main consensus nodes are downgraded to backup consensus nodes.

2. The method according to claim 1, characterized in that When any one of the business partitions is the underlying business partition, and the business attributes of the participants include the bid price and bid quantity of the investor, determining the decision weight of the primary consensus node of the participant in the any one of the business partitions based on the business attributes of the participants in the any one of the business partitions, so that the participants participate in consensus decision-making in the any one of the business partitions based on the decision weight, includes: According to the bid price and bid quantity of the investor in the underlying business partition, the decision weight of the investor's main consensus node in the underlying business partition is determined, so that the investor participates in consensus decision-making in the underlying business partition based on the decision weight.

3. The method according to claim 1, characterized in that The adopting of a preset heuristic distributed hash table algorithm to separately store the service data in the bottom service partition and the middle service partition includes: Counting the call frequency of each piece of business data in the bottom business partition and the middle business partition within a preset time period; Calculate the first redundancy corresponding to each piece of data according to the call frequency, and the data fault tolerance coefficient and the total number of accounting nodes corresponding to the bottom-layer business partition and the middle-layer business partition respectively; Based on the first redundancy, determining whether the number of accounting nodes of the service owner corresponding to each piece of data meets the redundancy requirement; If the number of accounting nodes of the business owner does not meet the redundancy requirement, a preset hash function is used to calculate the keyword corresponding to each piece of data, and based on the keyword and the identifiers of the existing accounting nodes in the bottom-layer business partition and the middle-layer business partition, a relevant target accounting node is matched for each piece of data from the existing accounting nodes; Based on the first redundancy, determining whether the number of accounting nodes of the service owner and the number of related target accounting nodes meet redundancy requirements; If the number of accounting nodes of the service owner and the number of related target accounting nodes do not meet the redundancy requirement, elastically expanding the first accounting node based on the first redundancy, the number of accounting nodes of the service owner and the number of target accounting nodes; Each piece of data is stored in the accounting node of the business owner, the target accounting node and the elastically expanded first accounting node respectively, and the identifier of the accounting node of the business owner, the identifier of the target accounting node and the identifier of the first accounting node are stored in the upper-layer business partition corresponding to the underlying business partition and the intermediate business partition respectively.

4. The method according to claim 3, characterized in that The method further comprises: When retrieving service data, query the upper-level service partition to obtain the identifier of the billing node of the service owner, the identifier of the target billing node, and the identifier of the first billing node; Based on the identifier of the billing node of the service owner, query the billing node of the service owner to read data; If the accounting node of the service owner fails, query the target accounting node according to the identifier of the target accounting node to read the data; If the target accounting node fails, the first accounting node is queried to read data according to the identifier of the first accounting node.

5. The method according to claim 1, wherein The adopting of a preset secret sharing algorithm to segment and store the service data in the top-level service partition includes: Obtaining a pre-configured second redundancy of the top-level service partition and the number of accounting nodes of the top-level service partition; If the number of accounting nodes in the top-level business partition does not meet the redundancy requirement, elastically expanding the second accounting node based on the second redundancy and the number of accounting nodes in the top-level business partition; Numbering the accounting nodes of the top-level business partition and the elastically expanded second accounting nodes; Evenly dividing the target block where the business data is located in the top-level business partition to obtain a plurality of divided blocks; randomly generating a polynomial according to the second redundancy; Based on the index value corresponding to the target block and the polynomial, the business data of each of the multiple partitioned blocks is stored in the corresponding numbered accounting node; The index value corresponding to the target block and the coefficient of the polynomial are respectively stored in a configuration block, wherein the configuration block does not participate in the segmentation and is stored in a corresponding accounting node.

6. The method according to claim 5, characterized in that The method further comprises: When performing business data retrieval, reading the index value corresponding to the target block and the coefficients of the polynomial from the configuration block; Based on the coefficients of the polynomial, the polynomial is restored, and the index value corresponding to the target block is brought into the polynomial for calculation to obtain a search keyword; Determine the number of the accounting node stored in each split block based on the search keyword; Searching for each split block from any available accounting node according to the number of the accounting node stored in each split block; Data recovery is performed based on each of the found partition blocks to obtain the target block.

7. A digital bond alliance chain dynamic partition consensus device, characterized by: include: A partitioning unit is used to partition the tree-like hierarchical digital bond alliance chain network into business partitions to obtain business partitions of different bond network layers, wherein the business partitions of different bond network layers include top-level business partitions, middle-level business partitions, and bottom-level business partitions; A first storage unit is configured to separately store the service data in the bottom service partition and the middle service partition using a preset heuristic distributed hash table algorithm; A second storage unit is used to divide and store the business data in the top-level business partition using a preset secret sharing algorithm; a decision-making unit configured to determine, for any one of the business partitions of the different bond network layers, a decision weight of the primary consensus node of the participant in the any one business partition according to the business attributes of the participant in the any one business partition, so that the participant participates in consensus decision-making in the any one business partition based on the decision weight; The upgrade and downgrade unit is configured to: for any one of the business partitions, if the system real-time requirement does not exceed the preset real-time requirement and the load of the main consensus node is less than the preset load, set a main consensus node; when the main consensus node fails, directly upgrade the backup consensus node to the main consensus node; if the system real-time requirement exceeds the preset real-time requirement, or the load of the main consensus node is greater than or equal to the preset load, set at least two main consensus nodes, and select one of the at least two main consensus nodes to participate in consensus decision-making; when the number of nodes of the at least two main consensus nodes is less than the preset number of nodes, upgrade the backup consensus node to the main consensus node; when the number of nodes of the at least two main consensus nodes is greater than or equal to the preset number of nodes, downgrade some of the at least two main consensus nodes to backup consensus nodes.

8. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

9. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

Images