Blockchain storage method and device, electronic equipment, storage medium and program product

Abstract

This application discloses a blockchain storage method, apparatus, electronic device, storage medium, and program product. The method is applied to a blockchain node, which deploys multiple database clients. The blockchain storage method includes: dividing the block data to be stored into multiple batches of block sub-data; distributing the multiple batches of block sub-data to multiple database clients; and having the multiple database clients concurrently write the received block sub-data to a database cluster. The blockchain storage method disclosed in this application divides the block data to be stored in the blockchain node into multiple batches of block sub-data and has the block sub-data concurrently written to the database cluster by different database clients in the blockchain node, thereby improving the writing efficiency of the block data to be stored.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a blockchain storage method, device, electronic device, storage medium, and program product. Background Technology

[0002] Blockchain technology is a novel distributed infrastructure and computing method that utilizes a block-chain data structure to verify and store data, distributed node consensus algorithms to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script code to program and manipulate data. Blockchain refers to a decentralized infrastructure with distributed storage characteristics; specifically, it is a data structure that organizes data blocks in chronological order using a linked list-like approach. It can securely store sequential data that can be verified within the system, and uses cryptography to ensure that the data is immutable and unforgeable.

[0003] Currently, blockchain storage includes single-node storage and distributed database storage. Single-node storage, due to the limitations of the storage server itself, cannot handle large amounts of data storage. Distributed database storage, which utilizes transactions provided by the distributed database, suffers from poor transaction performance, resulting in low storage efficiency. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a blockchain storage method, apparatus, electronic device, storage medium, and program product.

[0005] According to one aspect of the embodiments of this application, a blockchain storage method is provided, the blockchain storage method being applied to a blockchain node, wherein multiple database clients are deployed in the blockchain node, the method comprising:

[0006] Divide the block data to be stored into multiple batches of block sub-data;

[0007] Distribute the multiple batches of block sub-data to the multiple database clients;

[0008] The multiple database clients concurrently write the received block sub-data to the database cluster.

[0009] According to one aspect of the embodiments of this application, a blockchain storage device is provided, the blockchain storage device comprising:

[0010] The partitioning module is configured to divide the block data to be stored into multiple batches of block sub-data;

[0011] The distribution module is configured to distribute the multiple batches of block sub-data to the multiple database clients;

[0012] The write module is configured to allow the multiple database clients to concurrently write the received block sub-data to the database cluster.

[0013] According to one aspect of the embodiments of this application, an electronic device is provided, comprising:

[0014] Memory, which stores computer-readable instructions;

[0015] The processor reads computer-readable instructions stored in memory to execute any of the blockchain storage methods described above.

[0016] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the blockchain storage method as described above.

[0017] According to one aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in the blockchain storage method as described above.

[0018] In the technical solution provided by the embodiments of this application, by dividing the block data to be stored into multiple batches of block sub-data in the blockchain node, and writing the block sub-data concurrently into the database cluster by different database clients deployed in the blockchain node, the writing efficiency of the block data to be stored can be improved.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0021] Figure 1 This is a schematic diagram illustrating the structure of a blockchain network in an exemplary embodiment;

[0022] Figure 2 This is a schematic diagram of one implementation environment involved in this application;

[0023] Figure 3This is a schematic diagram of another implementation environment involved in this application;

[0024] Figure 4 This is a flowchart illustrating a blockchain storage method in an exemplary embodiment of this application;

[0025] Figure 5 This is a schematic diagram illustrating the effect of a blockchain storage method as shown in an exemplary embodiment of this application;

[0026] Figure 6 This is a flowchart illustrating a blockchain storage method in another exemplary embodiment of this application;

[0027] Figure 7 yes Figure 4 A flowchart of an exemplary embodiment following step S430 in the blockchain storage method shown;

[0028] Figure 8 yes Figure 7 Step S720 in the illustrated embodiment is a flowchart of an exemplary embodiment.

[0029] Figure 9 This is a flowchart illustrating a blockchain storage method as shown in another exemplary embodiment of this application;

[0030] Figure 10 This is an exemplary embodiment of the blockchain storage method shown in this application, which is a general flowchart.

[0031] Figure 11 This is a flowchart illustrating a blockchain node downtime situation in a blockchain storage method, as shown in an exemplary embodiment of this application;

[0032] Figure 12 yes Figure 11 The illustrated embodiment shows a flowchart of the blockchain node failure handling process in the blockchain storage method.

[0033] Figure 13 This is a block diagram illustrating a blockchain device in an exemplary embodiment of this application;

[0034] Figure 14 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0035] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0037] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0038] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0039] First, it should be noted that the embodiments of this application involve blockchain technology. Blockchain technology is a novel distributed infrastructure and computing method that utilizes a block-chain data structure to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script code to program and manipulate data. Blockchain refers to a decentralized infrastructure with distributed storage characteristics. Specifically, it is a data structure that organizes data blocks in chronological order using a linked list-like manner, enabling secure storage of sequentially related data that can be verified within the system, and using cryptography to ensure that the data is immutable and unforgeable. Simply put, blockchain is a decentralized distributed ledger, with each chain acting as an independent ledger.

[0040] Figure 1 This is a schematic diagram illustrating the structure of a blockchain network as shown in an exemplary embodiment. Figure 1The blockchain network 100 shown may include node devices 10a, 10b, 10c, and 10d. Node devices 10a, 10b, 10c, and 10d are all... Figure 1 The blockchain nodes (referred to as nodes) in the blockchain network 100 shown can be any form of computing device connected to the blockchain network 100, such as servers, user terminals, etc. Figure 1 The node devices 10a, 10b, 10c, and 10d shown can also be connected to form a blockchain network 100 through network communication.

[0041] It should be understood that Figure 1 The nodes in the illustrated blockchain network architecture can form a peer-to-peer (P2P) network. The P2P protocol here can be an application layer protocol running on top of the Transmission Control Protocol (TCP). In the network architecture corresponding to blockchain network 100, any machine, such as a server or terminal, can join and become a node. A node can specifically include a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0042] Each node in blockchain network 100 can be used to maintain the same blockchain ledger (i.e. Figure 1 The blockchain ledger 10e shown can be used to pre-deploy multiple smart contracts. For example, it can pre-deploy agent contracts, permission management contracts, data contracts, agent management contracts, and other smart contracts with different data processing functions. It should be understood that a smart contract is also a computerized protocol that can execute the terms of a contract. This is achieved through code deployed on the blockchain ledger that executes when certain conditions are met, and the code is used to automate transactions based on actual business needs.

[0043] Understandably, in Figure 1The blockchain network architecture shown includes three main types of blockchains: public blockchains, private blockchains, and consortium blockchains. The type of blockchain used may vary depending on the specific application scenario. A public blockchain is one that is publicly accessible, allowing anyone to join and access it. Blocks on a public blockchain can be viewed by anyone, and anyone can initiate transactions and participate in the consensus process. A private blockchain is used within a private organization, where read / write permissions and participation in record-keeping are determined according to the organization's rules; it is typically used for internal data management and auditing. A consortium blockchain allows members to define their read / write permissions and participation in record-keeping according to the consortium's rules; it is generally used for inter-institutional transactions, settlements, and clearing.

[0044] Figure 2 This is a schematic diagram of an implementation environment involved in this application. The implementation environment includes a blockchain node 210, which includes multiple database clients 211 and a database cluster 212. The blockchain node 210 and the multiple database clients 211 have pre-established wired or wireless network connections, and the multiple database clients 211 and the database cluster 212 have pre-established wired or wireless network connections.

[0045] like Figure 2 As shown, blockchain node 210 divides the block data to be stored into multiple batches of block sub-data and distributes the multiple batches of block sub-data to multiple database clients 211. Multiple database clients 211 receive the multiple batches of block sub-data distributed by blockchain node 210 and concurrently write the received multiple batches of block sub-data into database cluster 212. Database cluster 212 stores the multiple batches of block sub-data concurrently written by multiple database clients 211.

[0046] Furthermore, considering the storage bottleneck in the database cluster 212 within blockchain node 210, this application provides an alternative implementation environment to expand the storage capacity of the database cluster. For details, please refer to [link / reference needed]. Figure 3 . Figure 3 This is a schematic diagram of another implementation environment involved in this application. The implementation environment includes a blockchain node 310 and a database cluster 320. The blockchain node 310 includes multiple database clients 311. The blockchain node 310 and the multiple database clients 311 have a pre-established wired or wireless network connection, and the multiple database clients 311 and the database cluster 320 have a pre-established wired or wireless network connection.

[0047] like Figure 3As shown, blockchain node 310 divides the block data to be stored into multiple batches of block sub-data and distributes the multiple batches of block sub-data to multiple database clients 311. Multiple database clients 311 receive the multiple batches of block sub-data distributed by blockchain node 310 and concurrently write the received multiple batches of block sub-data into database cluster 320. Database cluster 320 stores the multiple batches of block sub-data concurrently written by multiple database clients 311.

[0048] in, Figure 2 or Figure 3 The blockchain node shown can be any terminal device that supports blockchain storage, such as a smartphone, in-vehicle computer, tablet, laptop, or wearable device, but is not limited to these. Figure 2 or Figure 3 The database cluster shown can be a storage server, such as a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. There are no restrictions on this.

[0049] Please see Figure 4 , Figure 4 This is a flowchart illustrating a blockchain storage method in an exemplary embodiment of this application. This blockchain storage method can be applied to... Figure 2 Alternatively, the implementation environment shown in Figure 3 may be used, and the method may be specifically executed by a blockchain node in that implementation environment. It should be understood that the method may also be applied to other exemplary implementation environments and executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which the method is applicable.

[0050] The following section will describe in detail the blockchain node method proposed in this application embodiment, using a blockchain node with storage, computing and processing functions as the specific execution subject.

[0051] like Figure 4 As shown, in an exemplary embodiment, the blockchain storage method includes at least steps S410 to S430, which are described in detail below:

[0052] Step S410: Divide the block data to be stored into multiple batches of block sub-data.

[0053] First, it's important to clarify that the block data to be stored refers to the data contained within the block to be stored. For example, the block data to be stored can include the block data in the block body and the block data in the block header. The block data in the block body includes input data, while the block data in the block header includes input information feature data, version data, timestamp data, and difficulty data, among other things. Additionally, for ease of storage, the block data to be stored is typically stored in a key-value pair format.

[0054] Block sub-data refers to a portion of the block data contained within the block to be stored.

[0055] Blockchain nodes divide the block data to be stored into multiple batches of block sub-data. It should be noted that, to improve concurrent write efficiency, blockchain nodes can divide the block data to be stored based on the attributes of the database clients themselves. For example, if a blockchain node includes 3 database clients and the block data to be stored contains 10 key-value pairs, the blockchain node can divide the 10 key-value pairs into 3 batches based on the 3 database clients. Each batch will contain 3, 4, and 3 key-value pairs respectively. In this case, the 3 key-value pairs constitute one batch of block sub-data. Alternatively, the blockchain node can divide the 10 key-value pairs into 2 batches, each batch containing 3 and 7 key-value pairs respectively. The embodiments of this application do not limit this approach.

[0056] Step S420: Distribute multiple batches of block sub-data to multiple database clients.

[0057] Blockchain nodes distribute the divided block data in multiple batches to multiple database clients. It should be noted that, to facilitate the distribution of multiple batches of block data to multiple database clients, blockchain nodes may also include a database client connection pool; see [link to documentation] for details. Figure 5 The database client connection pool comprises several database clients. The database client connection pool is used to distribute block data to be stored to multiple database clients. Blockchain nodes send the block data to be stored to the database client connection pool, and the database client connection pool allocates block sub-data based on the write capabilities of its constituent database clients or the number of database clients.

[0058] In step S430, multiple database clients concurrently write the received block sub-data to the database cluster.

[0059] A database cluster refers to a storage module for storing block data. A database cluster includes at least one database. For example, a database cluster can be a storage module contained within a block node, or it can be a remote storage module, i.e., a remote storage server.

[0060] Multiple database clients in a blockchain node concurrently write the received block sub-data to the database cluster.

[0061] like Figure 5 As shown, in order to facilitate multiple database clients in the blockchain node to concurrently write the received blockchain sub-data to the database cluster, the blockchain node in this embodiment also includes a database scheduling module, which is used to concurrently write the blockchain sub-data received by multiple database clients to the database clients.

[0062] It should be noted that the database scheduling module can implement concurrent write functionality independently, or it can exist in multiple database clients to achieve concurrent write functionality.

[0063] Additionally, it should be noted that, to ensure the atomicity of writing the block data to be stored, the height of the first latest block in the database cluster is determined by any one of the multiple database clients. The first latest block height can be understood as the sequence number of the block corresponding to the data to be stored in the database cluster, or as the number of blocks in the database cluster after the data to be stored has been written.

[0064] As can be seen, the blockchain storage method in this embodiment improves the writing efficiency of the block data to be stored by dividing the block data to be stored into multiple batches of block sub-data and writing the block sub-data into the database cluster concurrently by different database clients, compared with the prior art in which a single data client operates to write the block data to be stored into the database cluster.

[0065] Based on the above embodiments, considering that this application involves multiple database clients concurrently writing multiple batches of block sub-data into the database cluster, there is a possibility that the block data to be stored may not be completely written. Therefore, this embodiment provides the following solution to address the above technical problems.

[0066] like Figure 6 As shown, based on the above exemplary embodiments, before the step of dividing the block data to be stored into multiple batches of block sub-data, the blockchain storage method further includes at least steps S610 to S620, which are described in detail below:

[0067] Step S610: Cache the block data to be stored.

[0068] Blockchain nodes cache block data to be stored, enabling the retrieval of cached block data into the database cluster even before the data is fully written, thus ensuring the atomicity of the stored block data. For example, the block data to be stored can be cached in the write-ahead log (WAL) module of the blockchain node.

[0069] Step S620: Determine the second latest block height of the block data cached by the blockchain node.

[0070] The second latest block height refers to the block number corresponding to the block data to be stored after the blockchain node has cached the block data to be stored. For example, if the blockchain node caches the block data to be stored in the WAL system, then the second latest block height also refers to the number of blocks already cached in the WAL system.

[0071] The blockchain node determines the second latest block height of the block data cached by the blockchain node. For example, the blockchain node may determine the number of cached blocks in the write-ahead log module as the second latest block height.

[0072] It should be noted that, considering the limitations of cache space, to avoid the cache space limit affecting the caching of subsequent blocks to be stored, and thus affecting the recovery of blocks not fully written to the database cluster, blockchain nodes can retain a preset number of blocks of data in the cache space. For example, if the cache space is a write-ahead log module, the blockchain node can retain a preset number of blocks of data in the write-ahead log module. For instance, if the preset number of blocks is 5, the write-ahead log module sequentially caches the data of 5 blocks. Then, each time the blockchain node caches the data of a block to the write-ahead log module, it deletes the block data corresponding to the first sequence number in the WAL system, thus avoiding redundancy in the cache space.

[0073] As can be seen, the blockchain storage method in this embodiment caches the block data to be stored before dividing it into multiple batches of sub-block data, thus enabling the cached block data to be stored to be retrieved into the database cluster even when the block data to be stored has not been completely written to the database cluster, thereby ensuring the atomicity of the block data to be stored.

[0074] Based on the above embodiments, in order to determine whether multiple batches of block sub-data have been concurrently written to the database cluster, this embodiment provides the following solution.

[0075] like Figure 7As shown, based on the above exemplary embodiments, after the height of the first latest block in the database cluster is determined by any one of the multiple database clients, the blockchain storage method further includes at least steps S710 to S720, which are detailed below:

[0076] Step S710: Determine whether the height of the first latest block is equal to the height of the second latest block.

[0077] The blockchain node determines whether the height of the first latest block is equal to the height of the second latest block. If they are not equal, step S720 is executed. If they are equal, it indicates that multiple database clients have completely written multiple batches of block sub-data into the database cluster.

[0078] In step S720, the block data corresponding to the second latest block height is written to the database cluster.

[0079] The block data corresponding to the second latest block height refers to the latest cached block data of the blockchain node.

[0080] When a blockchain node determines that the height of the first latest block is not equal to the height of the second latest block, it writes the latest cached block data of the blockchain node into the database cluster.

[0081] As can be seen, the blockchain storage method in this embodiment determines whether the block data to be stored has been completely written into the database cluster by judging whether the second latest block data and the first latest block data are equal. If they are not equal, the latest cached block data of the blockchain node is written into the database cluster. This ensures that the cached block data to be stored can be retrieved into the database cluster when the block data to be stored has not been completely written into the database cluster, thus guaranteeing the atomicity of the block data to be stored.

[0082] Figure 8 yes Figure 7 The flowchart of step S720 in the illustrated embodiment is shown in an exemplary embodiment. (See attached flowchart.) Figure 8 As shown, based on the above exemplary embodiments, the process of writing the block data corresponding to the second latest block height to the database cluster may further include steps S810 to S820, which are detailed below:

[0083] Step S810: Determine the target block height, which is greater than the height of the first latest block, in the blockchain node.

[0084] The target block height refers to the height of the block cached by the blockchain node that is greater than the height of the latest block. For example, if a blockchain node caches the block data to be stored in the Write-Ahead Log (WAL) module, then the target block height is the block height among all the block data cached in the WAL module that is greater than the height of the latest block.

[0085] Given that the height of the first latest block is not equal to the height of the second latest block, there is a possibility that all the block data to be stored may not be written to the database cluster, or only a portion of the block data may be written to the database cluster. To ensure that all the block data to be stored is written to the database cluster, the blockchain nodes will determine a target block height that is greater than the height of the first latest block.

[0086] Step S820: Write the block data corresponding to the target block height to the database cluster.

[0087] Blockchain nodes write the block data corresponding to the target block height to the database cluster. For example, a blockchain node writes the block data corresponding to the target block height, which is greater than the height of the first latest block, from the write-ahead log module to the database cluster.

[0088] As can be seen, in the case that the height of the first latest block is not equal to the height of the second latest block, the blockchain storage method of this embodiment determines a target block height that is greater than the height of the first latest block in the blockchain node, and writes the block data corresponding to the target block height into the database cluster, thereby realizing the complete writing of the block data to be stored and ensuring the atomicity of the block data to be stored.

[0089] like Figure 9 As shown, based on the above exemplary embodiments, before the step of dividing the block data to be stored into multiple batches of block sub-data, the blockchain storage method further includes at least steps S910 to S920, which are detailed below:

[0090] Step S910: Serialize the block data to be stored to obtain serialized block data.

[0091] Serialization refers to converting block data to be stored into key-value pairs.

[0092] Blockchain nodes serialize the block data to be stored to obtain serialized block data.

[0093] Step S920: Deduplication is performed on the serialized block data.

[0094] Considering that duplicate blocks may exist within the data to be stored, leading to identical blocks being written, blockchain nodes perform deduplication on the serialized block data before dividing the deduplicated block data into multiple batches.

[0095] As can be seen, the blockchain storage method in this embodiment serializes the block data to be stored and deduplicatizes the serialized block data, thereby avoiding the same block data being written due to the existence of identical block data in the block data to be stored, thus improving the writing efficiency of block data.

[0096] To clearly describe the above embodiments, the following is based on... Figure 10 The detailed flowcharts in the document provide a complete explanation of the above embodiments. For example... Figure 10 As shown, a Block refers to the block to be stored, Tx(0) to Tx(...) refer to transaction data, BlockHeader refers to the block header data, and RWSet(0) to RWSet(...) refer to the read / write set data. The detailed process is as follows:

[0097] Specifically, blockchain nodes serialize the data of each block to be stored and cache the serialized block data in the Write-Ahead Log (WAL) system. Then, they deduplicate the serialized block data to obtain the deduplicated block data. Figure 10 A new key-value pair (KVS) is generated, and the deduplicated block data is sent to the database client connection pool. Then, the database client connection pool performs data partitioning on the block data to be stored, obtaining multiple batches of block sub-data, and distributes multiple batches of block sub-data to multiple database clients. Then, multiple database clients concurrently write multiple batches of block sub-data into the database cluster. Finally, any one of the multiple database clients updates the latest block height in the database cluster, which is the first latest block height.

[0098] It should be noted that the database client connection pool can divide the data to be stored into blocks based on the database clients it includes. That is, the amount of sub-block data in each batch can be dynamically adjusted, and the batch size can also be dynamically adjusted. For example, if the database client connection pool includes 3 database clients, and the data to be stored contains 10 key-value pairs, the database client connection pool can divide the 10 key-value pairs into 3 batches based on the 3 database clients. Each batch may contain 3, 4, and 3 key-value pairs respectively. In this case, the 3 key-value pairs constitute one batch of sub-block data. Alternatively, the database client connection pool can divide the 10 key-value pairs into 2 batches, each batch containing 3 and 7 key-value pairs respectively. The embodiments of this application do not limit this approach.

[0099] It should be further noted that the embodiments of this application, based on the concurrent writing of multiple batches of block sub-data to the database cluster by multiple database clients, improve the handling of blockchain node downtime. For details, please refer to [link / reference needed]. Figure 11 .

[0100] Figure 11 This is a flowchart illustrating a blockchain node downtime scenario in a blockchain storage method, as shown in an exemplary embodiment of this application. Figure 11 As shown, the blockchain storage method in this application embodiment further includes steps S1110 to S1130, which are described in detail below:

[0101] In step S1110, if a blockchain node crashes during the process of storing the block data to be stored in the database cluster, the third latest block height of the block data cached by the blockchain node is determined, as well as the fourth latest block height in the database cluster is determined.

[0102] Blockchain node downtime refers to a situation where a blockchain node is unable to store the blocks to be stored in the database cluster due to network or other reasons. It should be noted that blockchain node downtime can occur in various situations... Figure 10 This embodiment does not limit any step in the flowchart.

[0103] The third latest block height refers to the block height of the latest block data that the blockchain node has cached when the blockchain node crashes. For example, if the blockchain node caches the block data to be stored in the Write-Ahead Log (WAL) module, then the block height corresponding to the latest stored block data in the WAL module when the blockchain node crashes is the third latest block height.

[0104] The fourth latest block height refers to the latest block height updated by any one of the multiple database clients when a blockchain node fails. It should be noted that the fourth latest block height could be the block height updated after multiple batches of block sub-data have been written to the database cluster, or it could be the block height before multiple batches of block sub-data have been written to the database cluster; that is, the block height in the database cluster determined when the previous block data was written to the database cluster.

[0105] During the process of storing block data to be stored in the database cluster, the blockchain node checks for node downtime. If a downtime occurs, the third latest block height of the cached block data is determined, and the fourth latest block height in the database cluster is determined by any one of the multiple database clients. For example, if a downtime occurs, the blockchain node determines the block height corresponding to the most recently stored block data in the write-ahead log module as the third latest block height.

[0106] Step S1120: Determine whether the height of the third latest block is equal to the height of the fourth latest block.

[0107] The blockchain node determines whether the height of the third latest block is equal to the height of the fourth latest block. If they are not equal, step S1130 is executed. If they are equal, it indicates that multiple database clients have completely written multiple batches of block sub-data into the database cluster.

[0108] Step S1130: Write the block data corresponding to the height of the third latest block to the database cluster.

[0109] The block data corresponding to the third latest block height is the latest cached block data of the blockchain node when the blockchain node crashes.

[0110] When a blockchain node determines that the height of the third most recent block is not equal to the height of the fourth most recent block, it writes the block data corresponding to the height of the third most recent block to the database cluster. For example, a blockchain node can identify block data with a height greater than the height of the fourth most recent block in the write-ahead log module and write that block data to the database cluster.

[0111] It should be noted that, considering the possibility of duplicate block data in the latest cached block data when a blockchain node crashes, leading to duplicate write operations, to avoid this problem, the blockchain node can perform deduplication on the block data corresponding to the third latest block height before writing the deduplicated block data to the database cluster.

[0112] To clearly describe the above embodiments, the following is based on... Figure 12 The detailed flowchart illustrates the blockchain node downtime scenarios described in the above embodiments. For example... Figure 12 As shown, the details are as follows:

[0113] If a blockchain node detects a crash while storing block data to the database cluster, it retrieves the latest block height h0 (the fourth latest block height) from the database cluster and the latest block height h1 (the third latest block height) cached in the write-ahead log module. It then compares h0 and h1. If h0 equals h1, it indicates no data loss in the database cluster. If h0 is less than h1, it determines the block height greater than h0 from all block heights in the write-ahead log module. It then deduplicates the block data corresponding to these block heights and writes the deduplicated data into the database cluster in parallel. Any database client among multiple database clients updates the latest block height of the database cluster. Finally, it starts the operation of other modules.

[0114] As can be seen, in this embodiment of the blockchain storage method, if a blockchain node crashes during the process of storing the block data to be stored into the database cluster, the method determines the third latest block height of the cached block data and the fourth latest block height in the database cluster. It then determines whether the third latest block height is equal to the fourth latest block height. If the third latest block height is not equal to the fourth latest block height, the block data corresponding to the third latest block height is written into the database cluster. By utilizing multiple database clients to concurrently write multiple batches of block sub-data to the database cluster, the method improves the handling of blockchain node crashes and avoids data loss due to blockchain node failures.

[0115] Figure 13 This is a block diagram illustrating a blockchain storage device in an exemplary embodiment of this application. This blockchain storage device can be applied to... Figure 2 or Figure 3 The implementation environment shown is not limited to this blockchain storage device. This blockchain storage device can also be applied to other exemplary implementation environments, and this embodiment does not limit the implementation environment to which the blockchain storage device is applicable.

[0116] like Figure 13 As shown, the exemplary blockchain storage device 1300 includes a partitioning module 1310, a distribution module 1320, and a writing module 1330, specifically:

[0117] The partitioning module 1310 is configured to divide the block data to be stored into multiple batches of block sub-data. The block data to be stored refers to the data contained within the block to be stored. For example, the block data to be stored may include block data in the block body and block data in the block header. The block data in the block body includes input data, and the block data in the block header includes input information feature data, version data, timestamp data, and difficulty data, etc. It should also be noted that, for ease of storage, the block data to be stored is typically stored in a key-value pair format.

[0118] Block sub-data refers to a portion of the block data contained within the block to be stored.

[0119] It should be noted that, to improve concurrent write efficiency, blockchain nodes can divide the block data to be stored according to the attributes of the database clients. For example, if a blockchain node includes three database clients and the block data to be stored contains 10 key-value pairs, the blockchain node can divide the 10 key-value pairs into three batches based on the three database clients. Each batch will contain 3, 4, and 3 key-value pairs respectively. In this case, the 3 key-value pairs constitute one batch of block sub-data. Alternatively, the blockchain node can divide the 10 key-value pairs into two batches, each containing 3 and 7 key-value pairs respectively. The embodiments of this application do not limit this approach.

[0120] The distribution module 1320 is configured to distribute multiple batches of block sub-data to multiple database clients. To facilitate this distribution, the blockchain node may also include a database client connection pool, which contains several database clients. The database client connection pool is used to distribute the block data to be stored to multiple database clients. The blockchain node sends the block data to be stored to the database client connection pool, and the database client connection pool allocates block sub-data based on the write capabilities of its constituent database clients or the number of database clients.

[0121] The write module 1330 is configured to allow multiple database clients to concurrently write received block sub-data to a database cluster. Here, the database cluster refers to the storage module for storing block data. The database cluster includes at least one database. For example, the database cluster can be a storage module contained within a block node, or it can be a remote storage module, i.e., a remote storage server.

[0122] To facilitate the concurrent writing of received blockchain sub-data to the database cluster by multiple database clients within a blockchain node, the blockchain node in this embodiment also includes a database scheduling module. This module is used to concurrently write the received blockchain sub-data to the database clients. It should be noted that the database scheduling module can implement the concurrent write function independently, or it can exist within multiple database clients to achieve the concurrent write function.

[0123] In this exemplary blockchain storage device, the writing efficiency of the block data to be stored is improved by dividing the block data to be stored into multiple batches of block sub-data and writing the block sub-data concurrently into the database cluster by different database clients.

[0124] Based on the above exemplary embodiments, after the writing module 1330, the blockchain storage device 1300 further includes:

[0125] The module for determining the height of the first latest block is configured so that any one of multiple database clients can determine the height of the first latest block in the database cluster. The height of the first latest block can be understood as the sequence number of the block to be stored within the database cluster, or as the number of blocks in the database cluster after the data to be stored has been written to it.

[0126] In this exemplary blockchain storage device, the blockchain node determines the height of the first latest block in the database cluster through any one of multiple database clients, ensuring the atomicity of writing the block data to be stored.

[0127] Based on the above exemplary embodiments, before the partitioning module 1310, the blockchain storage device 1300 further includes:

[0128] The caching module is configured to cache block data to be stored. For example, the block data to be stored can be cached in the write-ahead log (WAL) module of the blockchain node.

[0129] The second latest block height determination module is configured to determine the second latest block height of the block data cached by the blockchain node. The second latest block height refers to the block sequence number corresponding to the block data to be stored after the blockchain node has cached the data. For example, if the blockchain node caches the block data to be stored in the WAL system, then the second latest block height also refers to the number of blocks already cached in the WAL system.

[0130] It should be noted that, considering the limitations of cache space, to avoid the cache space limit affecting the caching of subsequent blocks to be stored, and thus affecting the recovery of blocks not fully written to the database cluster, blockchain nodes can retain a preset number of blocks of data in the cache space. For example, if the cache space is a write-ahead log module, the blockchain node can retain a preset number of blocks of data in the write-ahead log module. For instance, if the preset number of blocks is 5, the write-ahead log module sequentially caches the data of 5 blocks. Then, each time the blockchain node caches the data of a block to the write-ahead log module, it deletes the block data corresponding to the first sequence number in the WAL system, thus avoiding redundancy in the cache space.

[0131] In this exemplary blockchain storage device, the blockchain node caches the block data to be stored before dividing it into multiple batches of sub-block data. This enables the cached block data to be stored to be retrieved into the database cluster even when the block data to be stored has not been completely written to the database cluster, thus ensuring the atomicity of the block data to be stored.

[0132] Based on the above exemplary embodiments, after the writing module 1330, the blockchain storage device 1300 further includes:

[0133] The first comparison module is configured to write the block data corresponding to the second latest block height to the database cluster if the height of the first latest block is not equal to the height of the second latest block. Here, the block data corresponding to the second latest block height refers to the latest cached block data of the blockchain node.

[0134] In this exemplary blockchain storage device, the blockchain node determines whether the block data to be stored has been completely written to the database cluster by judging whether the second latest block data cached before dividing the block data to be stored into multiple batches of block sub-data is equal to the first latest block data after multiple database clients concurrently write the received block sub-data to the database cluster. If they are not equal, the latest cached block data of the blockchain node is written to the database cluster. This ensures that the cached block data to be stored can be retrieved to the database cluster even when the block data to be stored has not been completely written to the database cluster, thus guaranteeing the atomicity of the block data to be stored.

[0135] Based on the above exemplary embodiments, the first comparison module further includes:

[0136] The target block height determination module is configured to determine the target block height, which is greater than the height of the first latest block, within the blockchain node. The target block height refers to the height of any block cached by the blockchain node whose height is greater than the height of the first latest block. For example, if the blockchain node caches the block data to be stored in the Write-Ahead Log (WAL) module, then the target block height is the block height among all the blocks cached in the WAL module that is greater than the height of the first latest block.

[0137] The target block height writing module is configured to write the block data corresponding to the target block height to the database cluster.

[0138] In this exemplary blockchain storage device, when the height of the first latest block is not equal to the height of the second latest block, the blockchain node determines a target block height that is greater than the height of the first latest block, and writes the block data corresponding to the target block height into the database cluster, thereby achieving complete writing of the block data to be stored and ensuring the atomicity of the block data to be stored.

[0139] Based on the above exemplary embodiments, the blockchain storage device 1300 further includes:

[0140] The module for determining the third and fourth latest block heights is configured to, during the process of a blockchain node storing block data to be stored into the database cluster, determine the third latest block height of the cached block data and the fourth latest block height in the database cluster if a blockchain node crashes. A blockchain node crash refers to a situation where a network or other reason prevents the blockchain node from storing the block data to be stored into the database cluster. It should be noted that a blockchain node crash can occur in various situations... Figure 10 This embodiment does not limit any step in the flowchart.

[0141] The third latest block height refers to the block height of the latest block data that the blockchain node has cached when the blockchain node crashes. For example, if the blockchain node caches the block data to be stored in the Write-Ahead Log (WAL) module, then the block height corresponding to the latest stored block data in the WAL module when the blockchain node crashes is the third latest block height.

[0142] The fourth latest block height refers to the latest block height updated by any one of the multiple database clients when a blockchain node fails. It should be noted that the fourth latest block height could be the block height updated after multiple batches of block sub-data have been written to the database cluster, or it could be the block height before multiple batches of block sub-data have been written to the database cluster; that is, the block height in the database cluster determined when the previous block data was written to the database cluster.

[0143] The second comparison module is configured to write the block data corresponding to the third latest block height to the database cluster if the height of the third latest block is not equal to the height of the fourth latest block.

[0144] In this exemplary blockchain storage device, if a blockchain node crashes while storing block data to be stored in the database cluster, it determines the third latest block height of the cached block data and the fourth latest block height in the database cluster. It then checks if the third latest block height equals the fourth latest block height. If the third latest block height does not equal the fourth latest block height, the block data corresponding to the third latest block height is written to the database cluster. By utilizing multiple database clients to concurrently write multiple batches of block sub-data to the database cluster, the device improves the handling of blockchain node crashes and prevents data loss due to blockchain node failure.

[0145] Based on the above exemplary embodiments, before the partitioning module 1310, the blockchain storage device 1300 further includes:

[0146] The serialization module is configured to serialize the block data to be stored, obtaining serialized block data. Serialization refers to converting the block data to be stored into key-value pairs.

[0147] The deduplication module is configured to perform deduplication processing on the serialized block data.

[0148] In this exemplary blockchain storage device, the blockchain node serializes the block data to be stored and deduplicates the serialized block data to avoid the same block data being written due to the existence of identical block data in the block data to be stored.

[0149] It should be noted that the blockchain storage device and the blockchain storage method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the blockchain storage device provided in the above embodiments can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not a limitation here.

[0150] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the blockchain storage method provided in the above embodiments.

[0151] Figure 14A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 14 The computer system 1400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0152] like Figure 14 As shown, the computer system 1400 includes a Central Processing Unit (CPU) 1401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1402 or programs loaded from storage portion 1408 into Random Access Memory (RAM) 1403, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1403. The CPU 1401, ROM 1402, and RAM 1403 are interconnected via bus 1404. An Input / Output (I / O) interface 1405 is also connected to bus 1404.

[0153] The following components are connected to I / O interface 1405: an input section 1406 including a keyboard, mouse, etc.; an output section 1407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to I / O interface 1405 as needed. Removable media 1411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1410 as needed so that computer programs read from them can be installed into storage section 1408 as needed.

[0154] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1409, and / or installed from removable medium 1411. When the computer program is executed by central processing unit (CPU) 1401, it performs various functions defined in the system of this application.

[0155] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0156] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0157] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0158] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the blockchain storage method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0159] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain storage method provided in the various embodiments described above.

[0160] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A blockchain storage method, characterized in that, The method is applied to a blockchain node, where a database client connection pool is deployed. The database client connection pool includes multiple database clients. The method includes: Sending the block data to be stored to the database client connection pool; The database client connection pool divides the block data to be stored into multiple batches of block sub-data according to the writing capabilities of the respective database clients included therein or the number of data end clients. Among them, the number of block sub-data in each batch and the number of batches can be dynamically adjusted according to the database clients included in the data client connection pool; The database client connection pool distributes the multiple batches of block sub-data to the multiple database clients; The multiple database clients concurrently write the received block sub-data into the database cluster.

2. The method according to claim 1, wherein After the step of the multiple database clients concurrently writing the received block sub-data into the database cluster, the method further includes: Any one of the multiple database clients determines the first latest block height in the database cluster.

3. The method according to claim 2, characterized in that Before the step of dividing the block data to be stored into multiple batches of block sub-data, the method further includes: Caching the block data to be stored; Determining the second latest block height of the block data cached by the blockchain node.

4. The method according to claim 3, wherein After the step of any one of the multiple database clients determining the first latest block height in the database cluster, the method further includes: If the first latest block height is not equal to the second latest block height, write the block data corresponding to the second latest block height into the database cluster.

5. The method according to claim 4, wherein The step of writing the block data corresponding to the second latest block height into the database cluster includes: Determining a target block height greater than the first latest block height in the blockchain node; Writing the block data corresponding to the target block height into the database cluster.

6. The method according to any one of claims 1-5, characterized in that, The blockchain storage method further includes: During the process of the blockchain node storing the block data to be stored into the database cluster, if it is detected that the blockchain node crashes, determine the third latest block height of the block data cached by the blockchain node and determine the fourth latest block height in the database cluster; If the third latest block height is not equal to the fourth latest block height, write the block data corresponding to the third latest block height into the database cluster.

7. The method according to any one of claims 1-5, characterized in that, Before the step of dividing the block data to be stored into multiple batches of block sub-data, the method further includes: Performing serialization processing on the block data to be stored to obtain serialized block data; Performing duplicate removal processing on the serialized block data.

8. A blockchain storage device, characterized in that, Deployed on a blockchain node, where a database client connection pool is deployed in the blockchain node. The database client connection pool includes multiple database clients. The blockchain storage device includes: A sending module configured to send the block data to be stored to the database client connection pool; A partitioning module, configured to partition the block data to be stored into multiple batches of block sub-data by the database client connection pool according to the writing capabilities of each database client included therein or the number of data-side clients, wherein the number of block sub-data in each batch and the number of batches can be dynamically adjusted according to the database clients included in the data client connection pool; A distribution module, configured to distribute the multiple batches of block sub-data to the multiple database clients by the database client connection pool; A writing module, configured to concurrently write the received block sub-data into the database cluster by the multiple database clients.

9. An electronic device, characterized in that, Comprising: A memory storing computer-readable instructions; A processor, reading the computer-readable instructions stored in the memory to execute the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, There are computer-readable instructions stored thereon, which, when executed by a processor of a computer, cause the computer to execute the method according to any one of claims 1-7.

11. A computer program product, characterized in that, Comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1-7.

Images