Block storage method, device, alliance chain system, computer-readable storage medium and program product for alliance chain

Abstract

The present application relates to a block storage method, device, alliance chain system, computer-readable storage medium and program product for alliance chain. Applied to the alliance chain system, the alliance chain system includes multiple storage layers with different first transaction types, each storage layer includes multiple transaction nodes, and the method includes: when any transaction node in the alliance chain system receives storage strategy change information, the hash value of the first block to be adjusted in the storage layer is obtained according to the storage strategy change information; according to the hash value of the first block, the storage strategy of the first block is obtained, and according to the storage strategy of the first block, the first storage layer corresponding to the first block is determined; according to the hash value of the first block and the node identifier of each transaction node corresponding to the first storage layer, the first backup transaction node for storing the first block in the first storage layer is obtained, and the first block is stored in the first backup transaction node. The use of this method can reduce storage overhead.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a block storage method, device, alliance chain system, computer-readable storage medium and program product for alliance chain. Background Art

[0002] A consortium chain is a blockchain that requires registration permission and is limited to participation by consortium members. The read and write permissions and bookkeeping permissions on the chain are determined according to consortium rules.

[0003] In traditional technology, the alliance chain system uses a full block copy stored in each transaction node, and each node can reach a consensus on instructions and data. Although it has good fault tolerance and high availability, as time goes by, the transaction volume on the chain continues to increase, accumulating a large amount of transaction history data, which leads to the problem of high storage overhead. Summary of the invention

[0004] Based on this, it is necessary to provide a block storage method, device, alliance chain system, computer-readable storage medium and program product for alliance chain that can reduce storage overhead in response to the above technical problems.

[0005] In a first aspect, the present application provides a block storage method for a consortium chain, which is applied to a consortium chain system, wherein the consortium chain system includes multiple storage layers with different first transaction types, each storage layer includes multiple transaction nodes, and each transaction node stores a block whose transaction type is the same as the first transaction type of the storage layer in which it is located; the method includes: when any transaction node in the consortium chain system receives storage policy change information, obtaining a hash value of a first block to be adjusted in the storage layer according to the storage policy change information; obtaining the storage policy of the first block according to the hash value of the first block, and determining the first storage layer corresponding to the first block according to the storage policy of the first block; obtaining a first backup transaction node for storing the first block in the first storage layer according to the hash value of the first block and the node identifier of each transaction node corresponding to the first storage layer, and storing the first block in the first backup transaction node.

[0006] In one of the embodiments, the method further includes: a storage strategy module in the alliance chain system periodically counts the number of times each block is accessed, and determines the second transaction type of each block based on the number of times each block is accessed; for each block, if the second transaction type of the block is different from the first transaction type of the storage layer where the block is located, the storage strategy of the block is updated according to the second transaction type of the block, and the storage strategy change information is sent to any transaction node in the alliance chain system.

[0007] In one of the embodiments, the method also includes: when any transaction node in the alliance chain system receives cluster topology version change information, it starts scanning from the starting point of the locally stored block hash stream in sequence until the end point of the block hash stream is scanned; after each time the hash value of the second block is scanned from the block hash stream, the second storage layer corresponding to the second block is determined according to the hash value of the second block; according to the hash value of the second block and the node identifier of each transaction node corresponding to the second storage layer, the second backup transaction node for storing the second block in the second storage layer is obtained, and the second block is stored in the second backup transaction node.

[0008] In one of the embodiments, the method further includes: when the cluster topology management module in the alliance chain system receives the configuration information of the newly added transaction node, it updates the cluster topology version number and sends the cluster topology version change information to any transaction node in the alliance chain system.

[0009] In one of the embodiments, the method further includes: any transaction node in the first storage layer determines whether it is a first backup transaction node for storing the first block; if not, if any transaction node in the first storage layer stores the first block, the first block is deleted; if so, if any transaction node in the first storage layer does not store the first block, the first block is obtained through the data migration module in the alliance chain system.

[0010] In one of the embodiments, the first transaction type includes at least two of a hot transaction type, a warm transaction type, and a cold transaction type.

[0011] In a second aspect, the present application further provides a block storage device for a consortium chain, which is applied to a consortium chain system, wherein the consortium chain system includes multiple storage layers with different first transaction types, each storage layer includes multiple transaction nodes, and each transaction node stores a block with a transaction type that is the same as the first transaction type of the storage layer in which it is located; the device includes:

[0012] The first determination module is used for obtaining the hash value of the first block to be adjusted in the storage layer according to the storage strategy change information when any transaction node in the alliance chain system receives the storage strategy change information;

[0013] A second determination module, configured to obtain a storage strategy of the first block according to the hash value of the first block, and determine a first storage layer corresponding to the first block according to the storage strategy of the first block;

[0014] The third determination module is used to obtain a first backup transaction node for storing the first block in the first storage layer according to the hash value of the first block and the node identifiers of each transaction node corresponding to the first storage layer, and store the first block in the first backup transaction node.

[0015] In one of the embodiments, the device also includes a first sending module, which is used for the storage strategy module in the alliance chain system to periodically count the number of times each block is accessed, and determine the second transaction type of each block based on the number of times each block is accessed; for each block, if the second transaction type of the block is different from the first transaction type of the storage layer where the block is located, the storage strategy of the block is updated according to the second transaction type of the block, and the storage strategy change information is sent to any transaction node in the alliance chain system.

[0016] In one of the embodiments, the device also includes a fourth determination module, which is used for scanning in sequence from the starting point of the locally stored block hash stream until the end point of the block hash stream is scanned when any transaction node in the alliance chain system receives cluster topology version change information; after each time the hash value of the second block is scanned from the block hash stream, the second storage layer corresponding to the second block is determined according to the hash value of the second block; according to the hash value of the second block and the node identifier of each transaction node corresponding to the second storage layer, the second backup transaction node for storing the second block in the second storage layer is obtained, and the second block is stored in the second backup transaction node.

[0017] In one of the embodiments, the device also includes a second sending module, which is used to update the cluster topology version number when the cluster topology management module in the alliance chain system receives the configuration information of the newly added transaction node, and send the cluster topology version change information to any transaction node in the alliance chain system.

[0018] In one of the embodiments, the device also includes a judgment module, which is used for any transaction node in the first storage layer to determine whether it belongs to the first backup transaction node for storing the first block; if not, if any transaction node in the first storage layer stores the first block, the first block is deleted; if so, if any transaction node in the first storage layer does not store the first block, the first block is obtained through the data migration module in the alliance chain system.

[0019] In one of the embodiments, the first transaction type includes at least two of a hot transaction type, a warm transaction type, and a cold transaction type.

[0020] In the third aspect, the present application also provides a consortium chain system, which includes multiple storage layers with different first transaction types, each storage layer includes multiple transaction nodes, and each transaction node stores blocks with a transaction type that is the same as the first transaction type of the storage layer in which it is located; each transaction node includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the steps of the method described in any one of the first aspects above.

[0021] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of any one of the methods described in the first aspect are implemented.

[0022] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of any one of the methods described in the first aspect.

[0023] The above-mentioned block storage method, device, alliance chain system, computer-readable storage medium and program product for alliance chain are applied to the alliance chain system. The alliance chain system includes multiple storage layers with different first transaction types. Each storage layer includes multiple transaction nodes. Each transaction node stores blocks with the same transaction type as the first transaction type of the storage layer. In other words, each transaction node no longer stores the full amount of blocks, but stores part of the blocks, thereby achieving the purpose of reducing storage overhead. In addition, when any transaction node in the alliance chain system receives storage strategy change information, it obtains the hash value of the first block to be adjusted in the storage layer according to the storage strategy change information, and then obtains the storage strategy of the first block according to the hash value of the first block, and determines the first storage layer corresponding to the first block according to the storage strategy of the first block, and then obtains the first backup transaction node for storing the first block in the first storage layer according to the hash value of the first block and the node identifier of each transaction node corresponding to the first storage layer, and stores the first block in the first backup transaction node. In other words, the storage layer where the block is located can be adjusted rather than fixed, so that the block can be placed on the appropriate storage layer as the access frequency of the block changes, which can significantly improve the overall performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0025] Figure 1 It is a flowchart of a block storage method for a consortium chain in one embodiment;

[0026] Figure 2 A schematic diagram of the principle of generating a block in one embodiment;

[0027] Figure 3 It is a flowchart of a block storage method for a consortium chain in another embodiment;

[0028] Figure 4 A schematic diagram of a cluster topology structure in one embodiment;

[0029] Figure 5 A schematic diagram of the interaction relationship between modules in an embodiment;

[0030] Figure 6 This is a schematic diagram of the architecture of a consortium chain system in one embodiment;

[0031] Figure 7 A schematic diagram of backup node selection in different situations in an embodiment;

[0032] Figure 8 It is a structural block diagram of a block storage device for a consortium chain in one embodiment;

[0033] Fig. 9 FIG. 4 is a diagram showing the internal structure of a transaction node in an embodiment. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0035] Before introducing the present application, some terms involved in the present application are explained below.

[0036] Alliance chain: It is a blockchain that requires registration and permission. It is limited to alliance members. The read and write permissions and the permission to participate in bookkeeping on the blockchain are formulated according to the alliance rules. The entire blockchain network is jointly maintained by member institutions. Network access is generally accessed through the gateway nodes of member institutions, and the consensus process is controlled by pre-selected nodes. Therefore, alliance chains generally do not adopt the mining mechanism of proof of work, but mostly use consensus algorithms such as PoS (Proof of Stake) or PBFT (Practical Byzantine Fault Tolerant), Raft (a method to achieve strong consistency in distributed systems). The biggest difference between alliance chains and other blockchain systems is that they are private and licensed. Compared with the transaction speed of public chains per second, alliance chain transactions are faster and transaction costs are greatly reduced.

[0037] Hyperledger Fabric: An open source project from the Linux Foundation, it is a modular blockchain framework and the de facto standard for enterprise blockchain platforms. The core of a blockchain network is a distributed ledger that records all transaction information that occurs in the network. Blockchain ledgers are usually defined as decentralized because each participant in the entire network keeps a copy of the blockchain ledger, and all participants work together to maintain the ledger. In addition to decentralization and collaboration, another notable feature of blockchain is that information can only be recorded in the blockchain in an append-only manner, and encryption technology is used to ensure that once a transaction is added to the ledger, it cannot be tampered with. Unlike open permissionless network systems that allow unknown participants to join the network (a proof-of-work protocol is required to ensure transaction validity and maintain network security), the ledger registers all members through MSP (Membership Service Provider). In a blockchain network, not only is ledger information shared, but the process of updating the ledger is also shared. The ledger in Hyperledger Fabric consists of two parts: "world state" and "blockchain". The world state is a database that stores the current value of a set of ledger states. Through the world state, the program can directly access the current value of a ledger state without having to traverse the entire transaction log to calculate the current value. The blockchain is a transaction log that records all the changes that have led to the current world state. Transactions are collected in blocks attached to the blockchain, which helps us understand the history of all the changes that have led to the current world state.

[0038] The development of the Internet has mastered a large amount of user data and created huge economic benefits, but it is also facing the crisis of user privacy leakage. Due to the lack of unified data standards among various industries, various departments lack the motivation to share data in order to maintain their own interests, resulting in the development level of these industries lagging far behind the development level of the Internet. Blockchain technology has built a trusted value Internet that can be jointly maintained by all participants, which can minimize the cost of data, the most important production resource, in circulation. The combination of blockchain and data, the most important social resource in the future, can release great social and commercial value. Because blockchain has the characteristics of decentralization, peer-to-peer transactions, data immutability, anonymity, etc., every step of data acquisition, data exchange and data analysis can be recorded on the chain, establishing a strong trust endorsement for data, greatly promoting the rapid development of the big data industry, and reconstructing the big data industry to establish a trusted data exchange value network. Compared with public chain technology, the alliance chain is positioned as a blockchain access system established by all participants with business ties. Each transaction node usually has a corresponding entity organization, and can join and exit the network only after authorization. It achieves a high degree of decentralization within the business system and the overall function of facilitating centralized management outside the system, and has been rapidly developed and widely used.

[0039] Distributed ledgers can be applied to the infrastructure of trusted data storage, focusing on the efficiency of data storage and search in a big data environment and the scalability of the system. The Hyperledger Fabric network maintains multiple copies of a ledger, which are kept consistent with other copies through a process called consensus. Each transaction node can reach a consensus on instructions and data, making the system have good fault tolerance and high availability. However, as time goes by, the transaction volume on the chain continues to increase, the number of blocks continues to grow, and a large amount of transaction history data has accumulated, which leads to the problem of high storage overhead.

[0040] There is currently a proposal to use a random strategy to select some backup nodes for blocks when backing up blocks that store data. However, since the hardware of each transaction node is different, this random strategy will also have the problem of unreasonable storage resource allocation.

[0041] Therefore, it is possible to consider dividing the transaction nodes according to their hardware configurations, and fully utilize the hardware characteristics of the transaction nodes when storing blocks. Furthermore, considering that data has a hot and cold life cycle, the access frequency is highest when the data is just generated, and the access popularity will be greatly reduced after a period of time. Therefore, the locality of data access can be used for optimization, that is, blocks with lower access frequencies can be transferred to transaction nodes with lower costs, so that resources can be used to improve the access speed of the latest hot data to optimize storage resource utilization.

[0042] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0043] In an exemplary embodiment, Figure 1 As shown, a block storage method for alliance chain is provided, which is applied to the alliance chain system. The alliance chain system includes multiple storage layers with different first transaction types, each storage layer includes multiple transaction nodes, and each transaction node stores blocks with the same transaction type as the first transaction type of the storage layer.

[0044] The transaction type includes at least two of the hot transaction type, the warm transaction type and the cold transaction type; for example, if the transaction type includes the hot transaction type, the warm transaction type and the cold transaction type, then the multiple storage layers include the hot storage layer, the warm storage layer and the cold storage layer. The hot storage layer is generally used to store blocks that are accessed very frequently; the cold storage layer is generally used to store blocks that are accessed very infrequently; the access frequency of the blocks stored in the warm storage layer is between the two, and the specific implementation method can be defined by a preset threshold range.

[0045] The storage layer that any transaction node is classified into is related to the hardware parameters of the transaction node. In one possible implementation, the transaction node to be joined sends a joining request carrying hardware parameter information to the cluster topology management module in any transaction node in the alliance chain system, and the cluster topology management module determines the storage layer to which the transaction node to be joined belongs based on the hardware parameter information of the transaction node to be joined; wherein the hardware parameter information includes at least one of the storage medium type, capacity, network bandwidth, etc. In another possible implementation, the transaction node to be joined sends a joining request carrying configuration information to the cluster topology management module in the alliance chain system, wherein the configuration information includes hierarchical information, and the hierarchical information is used to specify the storage layer to which the transaction node to be joined belongs; the cluster topology management module determines the storage layer to which the transaction node to be joined belongs based on the hierarchical information of the transaction node to be joined.

[0046] The storage layer and transaction node in which any block is stored are related to the storage strategy in the block header of the block. Before introducing how to determine the storage layer and transaction node in which a block is stored based on the storage strategy of the block, we first introduce how blocks with storage strategies are generated.

[0047] For the generation process of blocks with storage strategies, such as Figure 2As shown, a new policy option may be added to the application programming interface where the user sends the transaction data, so that the user can specify the transaction type, such as hot transaction type, warm transaction type and cold transaction type, through the transaction policy field, and then the storage policy module in the alliance chain system will obtain the transaction type of the transaction data sent by the user. Usually, after the user sends the transaction data, it is received by the transaction pool (TxPool) in the alliance chain system. The transaction pool includes multiple transaction queues, such as hot transaction queues, warm transaction queues and cold transaction queues, among which the hot transaction queue is used to store the transaction data of the hot transaction type; the warm transaction queue is used to store the transaction data of the warm transaction type; and the cold transaction queue is used to store the transaction data of the cold transaction type. It should be noted that the number of transaction queues is consistent with the number of storage layers. In other words, a separate transaction queue needs to be maintained for each different transaction type. Therefore, the transaction data is differentiated and processed according to the transaction type specified by the user in the transaction strategy field, and is grouped and packaged by different transaction queues in the transaction pool. For example, when the number of transaction data in any of the multiple transaction queues is greater than or equal to the preset number, all the transaction data in the transaction queue is packaged into a block, or after a preset time interval, all the transaction data in the transaction queue is packaged into a block, so that the block body contains transaction data of the same transaction type. The packaged blocks are then randomly witnessed for consensus and backed up. This method of packaging transaction data in multiple transaction queues can improve the efficiency of transaction data packaging, and can also better meet the needs of hierarchical configuration in the framework, making hierarchical storage more flexible and efficient.

[0048] For the process of determining in which storage layer and in which transaction node a block is stored according to the storage strategy of the block, reference may be made to the following steps 102 and 103 .

[0049] The block storage method for the alliance chain includes the following steps 101 to 103, wherein:

[0050] Step 101, when any transaction node in the alliance chain system receives storage strategy change information, it obtains the hash value of the first block to be adjusted in the storage layer according to the storage strategy change information.

[0051] Among them, any transaction node receiving storage strategy change information can be considered as the data placement module in any transaction node receiving storage strategy change information. The data placement module can receive storage strategy change information because the storage strategy module of any transaction node in the alliance chain system will periodically count the number of visits to each block, and determine the second transaction type of each block based on the number of visits to each block; for each block, if the second transaction type of the block is different from the first transaction type of the storage layer where the block is located, it means that the block is the first block to be adjusted in the storage layer, then the storage strategy of the block is updated according to the second transaction type of the block, and the storage strategy change information is sent to any transaction node in the alliance chain system.

[0052] For example, for a block stored in the cold storage layer, the storage strategy module of any transaction node has obtained statistics that the number of accesses to the block in a period of time has reached 1000 times, while the preset access threshold range corresponding to the warm storage layer is [500, 2000], and the preset access threshold range corresponding to the cold storage layer is [0, 500), so the block needs to be adjusted from the cold storage layer to the warm storage layer. At this time, the storage strategy module of any transaction node replaces the cold transaction type in the storage strategy of the block with the warm transaction type, and sends the storage strategy change information to any transaction node in the alliance chain system. In other words, the storage strategy module of any transaction node perceives the change in data temperature through the number of times users access each block in a period of time, and adjusts the storage strategy of the block in time.

[0053] When a block needs to adjust the storage layer, the hash value of the block can be directly obtained to implement storage layer adjustment related calculations only for the block. Exemplarily, the storage strategy change information can directly include the hash value of the first block, so that after receiving the storage strategy change information, the data placement module in any transaction node can directly obtain the hash value of the first block from the storage strategy change information.

[0054] When a block needs to adjust the storage layer, the hash values ​​of all blocks in the storage layer where the block is located can be scanned to achieve storage layer adjustment related calculations not only for the block, but also for other blocks belonging to the same storage layer as the block. Exemplarily, the storage policy change information may include a storage layer identifier, wherein different storage layer identifiers correspond to storage layers of different first transaction types; the data placement module in any transaction node can obtain the block set of all blocks in the storage layer corresponding to the storage layer identifier according to the storage layer identifier, scan the block hash values ​​in the block set, and obtain the hash value of the first block. It can be understood that the block set needs to be scanned multiple times, and after each scan to obtain the hash value of the first block, the following steps 102 and 103 need to be executed.

[0055] Step 102: Obtain a storage strategy for the first block according to the hash value of the first block, and determine a first storage layer corresponding to the first block according to the storage strategy for the first block.

[0056] Among them, the storage policy module of any transaction node stores a storage policy mapping table, and the storage policy mapping table includes multiple sets of one-to-one corresponding hash values ​​and storage strategies. Therefore, the data placement module in any transaction node can query the storage strategy of the first block from the storage strategy mapping table based on the hash value of the first block.

[0057] The storage strategy includes a transaction type corresponding to the first block, and the data placement module in any transaction node can determine a storage layer having the same first transaction type as the transaction type corresponding to the first block as the first storage layer corresponding to the first block. For example, if the transaction type corresponding to the first block is a hot transaction type, then the first storage layer corresponding to the first block is a hot storage layer.

[0058] Step 103, according to the hash value of the first block and the node identifiers of the transaction nodes corresponding to the first storage layer, obtain the first backup transaction node for storing the first block in the first storage layer, and store the first block in the first backup transaction node.

[0059] Among them, each storage layer corresponds to a transaction node list, and the transaction node list contains the node identifiers of all online transaction nodes in the corresponding storage layer. Therefore, after determining the first storage layer corresponding to the first block, the transaction node list corresponding to the first storage layer can be obtained, and then the data placement module in any transaction node can obtain the node identifiers of each transaction node corresponding to the first storage layer.

[0060] According to the hash value of the first block and the node identifiers of each transaction node corresponding to the first storage layer, a first backup transaction node for storing the first block in the first storage layer is obtained, including: any transaction node in the first storage layer obtains the cluster topology of multiple storage layers, and determines the corresponding transaction node list in the target storage layer according to the cluster topology, wherein the cluster topology includes the transaction node list of multiple storage layers; the data placement module in any transaction node in the first storage layer performs hash calculation on the hash value of the first block and each node identifier in the transaction node list of the first storage layer to obtain the weight of each transaction node in the transaction node list. After obtaining the weight of each transaction node in the transaction node list, in one example, the step of performing hash calculation on the weight of each transaction node in the transaction node list based on a pseudo-random hash function to obtain the matching degree of the first block and each transaction node in the transaction node list is performed multiple times, and after each time the matching degree of the first block and each transaction node in the transaction node list is obtained, the transaction node with the largest matching degree is selected as the first backup transaction node of the first block, until the number of selected first backup transaction nodes reaches a preset number. In another example, a hash calculation is performed on the weight of each transaction node in the transaction node list based on a pseudo-random hash function to obtain the matching degree between the first block and each transaction node in the transaction node list, and a preset number of transaction nodes with the largest matching degree are selected from the transaction node list as the first backup transaction nodes. This process can be regarded as a lottery process.

[0061] It should be noted that all transaction nodes in the first storage layer obtain the same calculation results from the above calculations. Therefore, each transaction node in the first storage layer can know whether it needs to back up the first block.

[0062] Storing the first block in the first backup transaction node includes: any transaction node in the first storage layer determines whether it belongs to the first backup transaction node for storing the first block; if not, if any transaction node in the first storage layer stores the first block, deleting the first block; if so, if any transaction node in the first storage layer does not store the first block, obtaining and storing the first block through the data migration module in the alliance chain system.

[0063] In the case that any transaction node in the first storage layer does not store the first block, the first block is obtained through the data migration module in the alliance chain system, including: the data placement module in any transaction node in the first storage layer sends a block acquisition request carrying the hash value of the first block to the data migration module, and receives the first block sent by the data migration module in response to the block acquisition request.

[0064] In addition, it should be noted that the above cluster topology management module, storage strategy module, data placement module and data migration module are all set in each transaction node in the alliance chain system. The consistency of data can be achieved between each module through mechanisms such as consensus.

[0065] The above block storage method for alliance chain is applied to the alliance chain system. The alliance chain system includes multiple storage layers with different first transaction types. Each storage layer includes multiple transaction nodes. Each transaction node stores blocks with the same transaction type as the first transaction type of the storage layer. In other words, each transaction node no longer stores all blocks, but stores some blocks, thereby achieving the purpose of reducing storage overhead. Among them, the division of storage layers is related to the hardware parameters of the transaction nodes. Each transaction node stores blocks with the same transaction type as the first transaction type of the storage layer, which fully utilizes the hardware performance of the transaction nodes and solves the problem of unreasonable allocation of storage resources.

[0066] In addition, when any transaction node in the alliance chain system receives storage strategy change information, it obtains the hash value of the first block to be adjusted in the storage layer according to the storage strategy change information, and then obtains the storage strategy of the first block according to the hash value of the first block, and determines the first storage layer corresponding to the first block according to the storage strategy of the first block, and then obtains the first backup transaction node for storing the first block in the first storage layer according to the hash value of the first block and the node identifier of each transaction node corresponding to the first storage layer, and stores the first block in the first backup transaction node. In other words, the storage layer where the block is located can be adjusted rather than fixed, so that the block can be placed on the appropriate storage layer as the access frequency of the block changes, which can significantly improve the overall performance of the system.

[0067] In an exemplary embodiment, the method further includes the following steps 201 and 202, wherein:

[0068] Step 201: When any transaction node in the alliance chain system receives cluster topology version change information, it starts scanning from the starting point of the locally stored block hash stream until it scans to the end point of the block hash stream.

[0069] Among them, any transaction node receiving the cluster topology version change information can be considered as the data placement module in any transaction node receiving the cluster topology version change information. The data placement module can receive the cluster topology version change information because when the cluster topology management module in any transaction node in the alliance chain system receives the configuration information of the newly added transaction node, it updates the cluster topology version number and sends the cluster topology version change information to any transaction node in the alliance chain system.

[0070] Any transaction node receives the cluster topology version change information, indicating that the cluster topology has changed and the cluster topology metadata stored locally in any transaction node is outdated. Therefore, it is necessary to scan sequentially from the starting point of the locally stored block hash stream, and execute step 202 after each scan until the end of the block hash stream is scanned.

[0071] The block hash stream is configured for any transaction node in the alliance chain system. The block hash stream organizes the block hash values ​​of all blocks in a streaming structure, and the block hash of the newly added block is located at the end of the block hash stream.

[0072] Step 202, after each time scanning the hash value of the second block from the block hash stream, determine the second storage layer corresponding to the second block according to the hash value of the second block; obtain the second backup transaction node for storing the second block in the second storage layer according to the hash value of the second block and the node identifier of each transaction node corresponding to the second storage layer, and store the second block in the second backup transaction node.

[0073] The above steps 102 and 103 can be regarded as a data placement algorithm. The specific implementation of step 202 can be implemented using the data placement algorithm. Therefore, the specific implementation of step 202 will not be described in detail here.

[0074] In an exemplary embodiment, Figure 3 As shown, a flowchart of another block storage method for alliance chain is provided, including the following steps:

[0075] After any transaction node in the alliance chain is started, it enters the initialization phase. The data placement module in any transaction node obtains the latest cluster topology version number from the cluster topology management module through the world state, and obtains the scan offset. The scan offset is the position of the transaction node when the previous round of scanning ends in the block hash stream.

[0076] Compare the latest cluster topology version number with the last locally persisted cluster topology version number. If the locally persisted cluster topology version number is smaller than the latest cluster topology version number, scan sequentially from the starting point of the locally stored block hash stream, that is, scan the block from 0 until the end of the block hash stream is scanned, and execute the data placement algorithm after each scan. If the locally persisted cluster topology version number is the same as the latest cluster topology version number, just continue scanning from the last scan offset, and execute the data placement algorithm after the scan to complete the initialization. It can be understood that after scanning all block hashes in this round, modify the scan offset and persist it locally.

[0077] After the initialization is completed, the event loop is entered, that is, any transaction node in the alliance chain system determines the event type. If the storage strategy changes, when the storage strategy change information is received, step 101 is executed, and the data placement algorithm is executed, that is, step 102 and step 103; if the cluster topology version changes, when the cluster topology version change information is received, step 201 is executed, and the data placement algorithm is executed. If the exit information is received, the event loop is no longer performed and the task is terminated directly.

[0078] Based on the above content, it is necessary to supplement the cluster topology management module that the cluster topology refers to the hierarchical network topology structure composed of all nodes currently online in the alliance. This structure has certain changes. In order to reduce the delay caused by synchronization, it is not required to achieve strong consistency with the actual topology structure in the scenario of this application, but the final consistency must be met. In the process of the data placement module's directional data placement algorithm, since the transaction node needs to select a backup node from the cluster topology when scanning the block hash, all transaction nodes need to maintain the metadata of the global cluster topology structure and synchronize it locally.

[0079] After the transaction node to be joined joins the alliance chain system, the transaction node will send a transaction message with a special mark. These transaction messages can be maintained in the world state of Fabric. The final cluster topology is as follows: Figure 4 The hierarchical tree structure shown in the figure. Each transaction node has a unique identifier, and each block can be mapped to different storage layers based on the data placement algorithm, and finally backed up to the specified number of transaction nodes in the storage layer. It should be noted that Figure 4 The nodes in refer to the transaction nodes in this application.

[0080] Regarding the data migration module, it is necessary to add that when the data placement module scans the block hash, the block acquisition task will be sent to the data migration module. First, in order to maintain the number of block backups when the transaction node exits, the storage load is shared when the new node joins. Secondly, when the storage strategy changes, the hot and cold blocks are migrated to the appropriate storage layer. During these processes, the transaction node must communicate with other transaction nodes in the alliance chain system to transmit data. Therefore, the functions of the data migration module are, first, to obtain block data from other transaction nodes through a block hash value, and second, to receive requests from other transaction nodes and return the corresponding data.

[0081] The interaction between the cluster topology management module, storage strategy module, data placement module and data migration module is as follows: Figure 5As shown in the figure, the cluster topology management module maintains the latest configuration information of the transaction node and notifies the cluster topology version changes. The storage strategy module is responsible for receiving transaction data of different transaction types, and packaging the same transaction type in the same block, generating a storage strategy in the block header, and tracking the hot and cold changes of the data according to the total number of block accesses over a period of time, and adjusting the storage strategy of the block. The data placement module is responsible for processing events from the cluster topology management module and the storage strategy module, and re-placing the block to the correct backup transaction node. The transaction node first scans the block hash to determine whether the block needs to be stored or deleted, and sends the corresponding task to the data migration module. Finally, the data migration module is responsible for enabling the alliance chain system to reach the target state of data placement.

[0082] Based on the above content, the architectural diagram of the alliance chain system is as follows Figure 6 As shown in Figure 1, the consortium chain system includes an interface layer, a consensus layer, a service layer, and a storage layer. The functions implemented in the interface layer include users sending transaction data (users can define storage strategies in this process) and users accessing blocks (based on which the number of accesses can be counted). The interface layer also includes other user interfaces for implementing other functions. The consensus layer includes block storage strategies, cluster topology maintenance, consensus, world status, block header synchronization, and permission control. The service layer includes data placement modules and data migration modules. The storage layer includes data structures and key-value pair storage.

[0083] This application improves the performance of the alliance chain system in various aspects, as follows:

[0084] The data placement algorithm satisfies the decentralized selection of backup transaction nodes, which is in line with the scenario of distributed ledgers. Through the information maintained in the world state of the ledger, each transaction node can independently determine the storage location of the block without making other requests to the centralized management node in the alliance chain system or interacting with other nodes, which has low overhead.

[0085] The data placement algorithm meets the requirements of uniformity, scalability, and randomness. Through the calculation method of pseudo-random hashing, data can be evenly distributed to each node, avoiding load imbalance between nodes. When it is necessary to add or delete a node, the pseudo-random hashing algorithm will only affect a small amount of data, and all data needs to be redistributed. The pseudo-random hashing algorithm uses a combination of hash functions and random number generators to make data distribution more random, thereby improving security and anti-attack capabilities, and making it unpredictable in advance.

[0086] The data placement algorithm meets the requirements of high efficiency. The node selection is based on a pseudo-random selection algorithm. Each time, the transaction node with the highest matching degree is selected, which can minimize the changes in the selection results caused by cluster changes and minimize the amount of data migration. Take the four cases of transaction node selection as an example. Figure 7As shown in Figure 1, (1) The lottery of 6 transaction nodes. Assuming that the block needs to select 3 backup transaction nodes, there are 6 transaction nodes to be selected. Calculate the matching degree of all transaction nodes with the block. At this time, the matching degree of transaction nodes 1, 4, and 6 with the block is the largest, so transaction nodes 1, 4, and 6 are selected as backup nodes, as shown in Figure 1. Figure 7 As shown in Figure (1) in . (2) The lottery after transaction node 3 exits. Transaction node 3 exits. Since transaction node 3 was not originally selected and is not responsible for storing this block, the selection result remains unchanged. The exit of transaction node 3 will not trigger data migration. If transaction node 3 rejoins the network, data migration will not be triggered either. Figure 7 As shown in Figure (2) in . (3) The lottery situation after transaction node 6 exits. When transaction node 6 exits, the blocks it is responsible for backing up need to be backed up by a new node. At this time, transaction node 2 is newly selected as the new backup node, as shown in Figure 7 As shown in Figure (3), the exit of a backup node only requires a new node to re-backup the block, resulting in a small amount of data migration. (4) The lottery results after the addition of the new transaction node 7. The new transaction node 7 is added. The matching degree between the new transaction node 7 and the block is greater than that of all other nodes. Transaction node 2 is removed from the selection result and replaced by the new transaction node 7. In summary, when the cluster topology changes, whether a transaction node exits, a transaction node restarts, or a new transaction node joins, at most one data migration will occur, and the probability of change decreases as the number of transaction nodes increases. Based on this data placement algorithm, the backup node is selected to minimize the amount of block migration.

[0087] It should be noted that Figure 7 The nodes in the figure all refer to transaction nodes. Due to limited space in the figure, transaction nodes are shown as nodes.

[0088] For the trusted storage scenario of big data in the alliance chain, a solution for node stratification and hot and cold block definition is proposed to build a stratified cluster topology structure and make full use of the hardware characteristics of the node. The storage strategy of the block is adjusted according to the hot and cold changes of the data. The framework supports the configurability of stratification rules and the definability of storage strategies. It is highly flexible and customizable and can adapt to different business scenarios.

[0089] In order to cope with the dynamics of cluster topology and storage strategy, timely adjust the backup location of the block, perceive the temperature change of the data, and adjust the storage strategy of the block. Place hot data in the high-performance storage layer, archive cold data in the low-cost storage layer, migrate data periodically, and realize the reasonable allocation of storage resources, which greatly improves storage performance and reduces storage costs.

[0090] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0091] Based on the same inventive concept, the embodiment of the present application also provides a block storage device for alliance chain for implementing the above-mentioned block storage method for alliance chain. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above-mentioned method, so the specific limitations in the embodiments of one or more block storage devices for alliance chain provided below can refer to the limitations of the block storage method for alliance chain above, and will not be repeated here.

[0092] In an exemplary embodiment, Figure 8 As shown, a block storage device for alliance chain is provided, which is applied to the alliance chain system. The alliance chain system includes multiple storage layers with different first transaction types, each storage layer includes multiple transaction nodes, and each transaction node stores blocks with the same transaction type as the first transaction type of the storage layer. The block storage device 800 for alliance chain includes: a first determination module 801, a second determination module 802 and a third determination module 803, wherein:

[0093] The first determination module 801 is used for obtaining the hash value of the first block to be adjusted in the storage layer according to the storage strategy change information when any transaction node in the alliance chain system receives the storage strategy change information;

[0094] A second determination module 802 is used to obtain a storage strategy of the first block according to the hash value of the first block, and determine a first storage layer corresponding to the first block according to the storage strategy of the first block;

[0095] The third determination module 803 is used to obtain a first backup transaction node for storing the first block in the first storage layer according to the hash value of the first block and the node identifiers of the transaction nodes corresponding to the first storage layer, and store the first block in the first backup transaction node.

[0096] In one of the embodiments, the device also includes a first sending module, which is used for the storage strategy module in the alliance chain system to periodically count the number of times each block is accessed, and determine the second transaction type of each block based on the number of times each block is accessed; for each block, if the second transaction type of the block is different from the first transaction type of the storage layer where the block is located, the storage strategy of the block is updated according to the second transaction type of the block, and the storage strategy change information is sent to any transaction node in the alliance chain system.

[0097] In one of the embodiments, the device also includes a fourth determination module, which is used for scanning in sequence from the starting point of the locally stored block hash stream until the end point of the block hash stream is scanned when any transaction node in the alliance chain system receives cluster topology version change information; after each time the hash value of the second block is scanned from the block hash stream, the second storage layer corresponding to the second block is determined according to the hash value of the second block; according to the hash value of the second block and the node identifier of each transaction node corresponding to the second storage layer, the second backup transaction node for storing the second block in the second storage layer is obtained, and the second block is stored in the second backup transaction node.

[0098] In one of the embodiments, the device also includes a second sending module, which is used to update the cluster topology version number when the cluster topology management module in the alliance chain system receives the configuration information of the newly added transaction node, and send the cluster topology version change information to any transaction node in the alliance chain system.

[0099] In one of the embodiments, the device also includes a judgment module, which is used for any transaction node in the first storage layer to determine whether it belongs to the first backup transaction node for storing the first block; if not, if any transaction node in the first storage layer stores the first block, the first block is deleted; if so, if any transaction node in the first storage layer does not store the first block, the first block is obtained through the data migration module in the alliance chain system.

[0100] In one of the embodiments, the first transaction type includes at least two of a hot transaction type, a warm transaction type, and a cold transaction type.

[0101] Each module in the above-mentioned block storage device for alliance chain can be implemented in whole or in part by software, hardware and their combination. Each of the above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the corresponding operations of each of the above modules.

[0102] In an exemplary embodiment, a consortium chain system is provided, the consortium chain system comprising a plurality of storage layers with different first transaction types, each storage layer comprising a plurality of transaction nodes, each transaction node storing a block having a transaction type identical to the first transaction type of the storage layer in which it is located. Each transaction node is a computer device, such as Fig. 9 As shown, it includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be realized through WIFI, a mobile cellular network, near field communication (Near Field Communication, NFC) or other technologies. When the computer program is executed by the processor, a block storage method for an alliance chain is realized. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0103] Those skilled in the art will understand that Fig. 9 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0104] In an exemplary embodiment, the transaction node includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the method described in any of the above method embodiments when executing the computer program.

[0105] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method described in any of the above method embodiments are implemented.

[0106] In one embodiment, a computer program product is provided, including a computer program, which, when executed by a processor, implements the steps of the method described in any of the above method embodiments.

[0107] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0108] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0109] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be construed as limiting the scope of the present application. It should be noted that, for a person of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A block storage method for alliance chain, characterized in that: Applied to a consortium chain system, the consortium chain system includes multiple storage layers with different first transaction types, each of the storage layers includes multiple transaction nodes, and each of the transaction nodes stores a block with a transaction type that is the same as the first transaction type of the storage layer in which it is located; the method includes: When any transaction node in the alliance chain system receives the storage strategy change information, it obtains the hash value of the first block to be adjusted in the storage layer according to the storage strategy change information; Obtaining a storage strategy for the first block according to the hash value of the first block, and determining a first storage layer corresponding to the first block according to the storage strategy for the first block; According to the hash value of the first block and the node identifiers of the transaction nodes corresponding to the first storage layer, a first backup transaction node for storing the first block in the first storage layer is obtained, and the first block is stored in the first backup transaction node.

2. The method according to claim 1, characterized in that The method further comprises: The storage strategy module in the alliance chain system periodically counts the number of times each block is accessed, and determines the second transaction type of each block according to the number of times each block is accessed; For each block, if the second transaction type of the block is different from the first transaction type of the storage layer where the block is located, the storage strategy of the block is updated according to the second transaction type of the block, and the storage strategy change information is sent to any transaction node in the alliance chain system.

3. The method according to claim 1, characterized in that The method further comprises: When any transaction node in the alliance chain system receives the cluster topology version change information, it starts scanning from the starting point of the locally stored block hash stream in sequence until it scans to the end point of the block hash stream; After each time a hash value of a second block is obtained by scanning the block hash stream, a second storage layer corresponding to the second block is determined according to the hash value of the second block; a second backup transaction node for storing the second block in the second storage layer is obtained according to the hash value of the second block and the node identifiers of the transaction nodes corresponding to the second storage layer, and the second block is stored in the second backup transaction node.

4. The method according to claim 3, characterized in that The method further comprises: When the cluster topology management module in the alliance chain system receives the configuration information of the newly added transaction node, it updates the cluster topology version number and sends cluster topology version change information to any transaction node in the alliance chain system.

5. The method according to claim 1, characterized in that The method further comprises: Any transaction node in the first storage layer determines whether it is a first backup transaction node for storing the first block; If not, in the case where any transaction node in the first storage layer stores the first block, deleting the first block; If so, if any transaction node in the first storage layer does not store the first block, the first block is obtained through the data migration module in the alliance chain system.

6. The method according to claim 1, characterized in that The first transaction type includes at least two of a hot transaction type, a warm transaction type, and a cold transaction type.

7. A block storage device for alliance chain, characterized in that: Applied to a consortium chain system, the consortium chain system includes a plurality of storage layers with different first transaction types, each of the storage layers includes a plurality of transaction nodes, each of the transaction nodes stores a block with a transaction type that is the same as the first transaction type of the storage layer in which it is located; the device includes: A first determination module is used for obtaining a hash value of a first block to be adjusted in the storage layer according to the storage strategy change information when any transaction node in the alliance chain system receives the storage strategy change information; a second determination module, configured to obtain a storage strategy of the first block according to the hash value of the first block, and determine a first storage layer corresponding to the first block according to the storage strategy of the first block; The third determination module is used to obtain a first backup transaction node for storing the first block in the first storage layer according to the hash value of the first block and the node identifiers of each transaction node corresponding to the first storage layer, and store the first block in the first backup transaction node.

8. A consortium chain system, characterized in that: The alliance chain system includes multiple storage layers with different first transaction types, each of the storage layers includes multiple transaction nodes, each of the transaction nodes stores blocks with a transaction type that is the same as the first transaction type of the storage layer in which it is located, each of the transaction nodes includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of any one of the methods of claims 1 to 6 when executing the computer program.

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

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images