Block chain-based data processing method and related equipment

Abstract

The embodiment of the invention provides a data processing method based on a block chain and related equipment, a storage system corresponding to a node where the block chain is located comprises a block database, at least one state database and a metadatabase, and the state database is used for storing an index generated in a block and state data corresponding to the index. The method comprises the steps of writing block data of a to-be-stored block into a block database based on metadata information of the block database recorded in a metadatabase; according to the smart contract corresponding to the to-be-stored block, determining a target state database used for storing the to-be-stored index in the to-be-stored block and the corresponding state data from at least one state database; according to the method, the to-be-stored index and the corresponding state data are stored in the target state database based on the metadata information of the target state database recorded in the metadatabase, and the block height in the target state database is updated based on the to-be-stored block, so that the storage efficiency and the storage performance of the block chain data can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a blockchain-based data processing method and related equipment. Background Technology

[0002] Blockchain systems are called distributed data systems. Each node in a blockchain system has its own storage system, which stores data in key-value pairs. Currently, each node's storage system includes a database that stores all keys. However, in blockchain systems, when the amount of data is very large, both writing and querying data to the database become significant bottlenecks, severely impacting the storage performance and efficiency of blockchain data. Summary of the Invention

[0003] This application provides a data processing method and related equipment based on blockchain, which can improve the storage efficiency and performance of blockchain data.

[0004] On one hand, this application provides a data processing method based on blockchain. The blockchain node corresponds to a storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the state data corresponding to those indexes. The metadata database records the metadata information of each state database and the metadata information of the block database. The method includes:

[0005] Obtain the metadata information of the block database that has been recorded in the metadata database, and write the block data of the block to be stored into the block database based on the metadata information of the block database;

[0006] Obtain the index to be stored in the block to be stored, where the index corresponds to state data;

[0007] Based on the smart contract corresponding to the block to be stored, a target state database for storing the index to be stored and the corresponding state data is determined from at least one state database.

[0008] Based on the metadata information of the target state database already recorded in the metadata database, the index to be stored and the corresponding state data are stored in the target state database, and the block height in the target state database is updated based on the block to be stored.

[0009] On one hand, this application provides a blockchain-based data processing device. The blockchain node corresponds to a storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores indexes generated in the blocks and the corresponding state data. The metadata database records metadata information from each state database and the block database. The device includes:

[0010] The acquisition unit is used to acquire metadata information of the block database that has been recorded in the metadata database;

[0011] The processing unit is used to write the block data of the acquired block to be stored into the block database based on the metadata information of the block database;

[0012] The acquisition unit is further configured to acquire the index to be stored in the block to be stored, and the index to be stored corresponds to state data;

[0013] The processing unit is further configured to determine, based on the smart contract corresponding to the block to be stored, a target state database for storing the index to be stored and the corresponding state data from at least one state database.

[0014] The processing unit is further configured to store the index to be stored and the corresponding state data into the target state database based on the metadata information of the target state database already recorded in the metadata database, and update the block height in the target state database based on the block to be stored.

[0015] On one hand, embodiments of this application provide a computer device, the computer device comprising:

[0016] A processor is used to execute computer programs;

[0017] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the blockchain-based data processing method described above.

[0018] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program that is loaded by a processor and executed as described above regarding the blockchain-based data processing method.

[0019] On the one hand, embodiments of this application provide a computer program product, which includes a computer program or computer instructions, and when the computer program or computer instructions are executed by a processor, they implement the above-described blockchain-based data processing method.

[0020] In this embodiment, the blockchain node has a corresponding storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the corresponding state data. The metadata database records the metadata information of each state database and the metadata information of the block database. Therefore, this embodiment provides a completely new storage system for the node, allowing for separate storage and management of blockchain-related data (such as block data, state data, etc.). This avoids the performance issues associated with storing all blockchain data in a single database and improves the efficiency of blockchain data storage. The process involves: obtaining the metadata information of the block database already recorded in the metadata database; writing the block data of the block to be stored into the block database based on the metadata information; obtaining the index to be stored in the block to be stored, which corresponds to state data; determining a target state database from at least one state database to store the index and corresponding state data based on the smart contract corresponding to the block to be stored; storing the index and corresponding state data in the target state database based on the metadata information of the target state database already recorded in the metadata database; and updating the block height in the target state database based on the block to be stored. As can be seen, this embodiment can obtain metadata information of the corresponding database recorded in the metadata database, thereby storing block data and state data in the block into the corresponding databases respectively. This avoids the problem of low storage efficiency caused by storing data in a single database simultaneously, thus improving the storage efficiency and performance of blockchain data. Furthermore, this embodiment selects a state database for state data storage according to the smart contract. This allows for differentiated storage of state data corresponding to each smart contract, reducing the impact on data storage performance caused by the different storage resources occupied by indexes generated by smart contracts and the corresponding state resources, and further improving the storage efficiency and performance of blockchain data. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1A An architecture diagram of a blockchain system provided in this application embodiment;

[0023] Figure 1B A schematic diagram of a blockchain provided for an embodiment of this application;

[0024] Figure 1CA block generation schematic diagram provided for an embodiment of this application;

[0025] Figure 2 An architecture diagram of a blockchain-based data processing system provided in this application embodiment;

[0026] Figure 3 A schematic diagram of a storage system provided in an embodiment of this application;

[0027] Figure 4 This application provides a schematic diagram illustrating the use of a block database in an embodiment.

[0028] Figure 5 A schematic diagram of a state database provided in an embodiment of this application;

[0029] Figure 6 A schematic diagram of a metadata database provided in an embodiment of this application;

[0030] Figure 7 A flowchart illustrating a blockchain-based data processing method provided in this application embodiment;

[0031] Figure 8 A schematic diagram illustrating the data synchronization process between a cache and a metadata database, provided as an embodiment of this application;

[0032] Figure 9 A schematic diagram of a data storage process provided in an embodiment of this application;

[0033] Figure 10 A flowchart illustrating another blockchain-based data processing method provided in this application embodiment;

[0034] Figure 11 This application provides a specific data query process illustration;

[0035] Figure 12 A schematic diagram of the structure of a blockchain-based data processing device provided in this application embodiment;

[0036] Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0037] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0038] This application provides a blockchain system, see [link / reference] Figure 1A The blockchain system shown, blockchain system 100, refers to a system for data sharing between nodes. This blockchain system may include multiple nodes 101, which can refer to various clients within the blockchain system. Each node 101, in its normal operation, receives input information (such as transactions) and maintains shared data within the blockchain system based on the received input information. To ensure information interoperability within the blockchain system, information connections can exist between each node, allowing for information transmission between nodes. For example, when any node in the blockchain system receives input information, other nodes in the blockchain system obtain this input information according to a consensus algorithm and store it as data in the shared data, ensuring consistency of data stored on all nodes in the blockchain system.

[0039] Each node in a blockchain system has a corresponding node identifier. Furthermore, each node can store the node identifiers of other nodes in the blockchain system, allowing it to broadcast generated blocks to other nodes based on their identifiers. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier accordingly. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 uses IP addresses as an example.

[0040] Node name Node identification Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.XXX.XXX

[0041] Each node in a blockchain system stores the same blockchain entry. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 1B A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0042] When generating the individual blocks in the blockchain, see Figure 1CWhen a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

[0043] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0044] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0045] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node containing the blockchain sends the newly generated block to other nodes in its blockchain system based on the node identifiers of other nodes in the blockchain system. The other nodes verify the newly generated block and add it to their stored blockchain after verification.

[0046] Currently, most common blockchain storage uses a key-value approach, and key-value databases typically provide get (query) and set (write) operations. In blockchain systems, when the amount of blockchain data is large, both querying and writing become significant bottlenecks, impacting overall blockchain data processing performance. Therefore, this application provides a blockchain-based data processing solution, which can be considered a general storage optimization scheme. In this scheme, each node corresponds to a storage system, including a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the corresponding state data. The metadata database records the metadata information of each state database and the block database. The metadata information may include, but is not limited to, access addresses, etc. As can be seen, this application provides a general storage system for nodes, allowing for the separate storage of block data, block indexes, and corresponding state data. This avoids the inefficient storage problem caused by storing all indexes and their corresponding state data in a single database, thus improving blockchain data storage efficiency and performance. Furthermore, by introducing a metadata database, this embodiment of the application can more flexibly add metadata information to the corresponding database, solving the problem that access links for databases (such as non-distributed databases) are configured and require restarting the blockchain system after adjusting the database access links. In other words, by introducing a metadata database, this embodiment of the application can directly store (record) the metadata information of the database into the metadata database. This eliminates the need to write access links separately in the configuration file, but instead uses the database, which is more flexible. Even if new links are added, they can be added directly through the metadata database, making the entire blockchain data processing highly scalable.

[0047] In one implementation, when storing data in a block, the metadata information of the block database already recorded in the metadata database can be directly obtained, and based on the metadata information of the block database, the block data of the block to be stored is written into the block database; and, the index to be stored in the block to be stored is obtained, the index to be stored corresponding to state data; according to the smart contract corresponding to the block to be stored, a target state database for storing the index to be stored and the corresponding state data is determined from at least one state database; at least one smart contract is deployed on the blockchain; based on the metadata information of the target state database already recorded in the metadata database, the index to be stored and the corresponding state data are stored in the target state database, and the block height in the target state database is updated based on the block to be stored.

[0048] As can be seen, this embodiment can obtain metadata information of the corresponding database recorded in the metadata database, thereby storing the block data and state data of the block to be stored in the corresponding database respectively. This avoids the problem of low storage efficiency caused by storing data in a single database simultaneously, thus improving the efficiency of blockchain data processing. Furthermore, this embodiment selects a state database for state data storage according to the smart contract. This allows for differentiated storage of state data corresponding to each smart contract, reducing the impact on data storage performance caused by the different storage resources occupied by indexes generated by smart contracts and the corresponding state resources. This also improves the efficiency of blockchain data processing to a certain extent.

[0049] The following section will describe the blockchain-based data processing system provided in the embodiments of this application.

[0050] Please see Figure 2 This is an architecture diagram of a blockchain-based data processing system provided in an embodiment of this application. The blockchain-based data processing system may include a blockchain system 100 and a storage system 102, wherein each node in the blockchain system may correspond to a storage system 102. Furthermore, the blockchain-based data processing system may also include a business system 103; the business system 103 can interact with any node 101 in the blockchain system 100, and the nodes 101 in the blockchain system 100 can interact with their respective storage systems 102. The following sections will describe each system in detail:

[0051] (1) Storage System

[0052] Please see Figure 3 This is a schematic diagram of a storage system provided in an embodiment of this application. Figure 3 In this system, storage system 102 includes at least a block data database (BlockdataDB), at least one state data database (StatedataDB), and a metadata database (MetadataDB), such as... Figure 3 In this embodiment, the storage system includes state database 1, state data 2, and so on; optionally, the storage system may also include a filtering database. The various databases provided in the embodiments of this application will be described below.

[0053] ① Block Database: Used to store block data in the blockchain, including but not limited to block headers, transactions, etc. The block database has the largest storage capacity, but the query demand is relatively low. Therefore, in this embodiment, the block database can be used in various ways, such as... Figure 4As shown, in one implementation, the block database stores the block data (i.e., the original information) of the blocks. The blockchain system can store the block data in the form of files and store the file index information in the block database. In another implementation, the block data in the block database can be stored in the form of a database. In yet another implementation, the block data in the block database can be stored in the form of cloud storage. Cloud storage is a new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to aggregate a large number of storage devices (also called storage nodes) of various types in the network through application software or application interfaces to work together and jointly provide data storage and business access functions. It should be understood that, in the embodiments of this application, when writing block data to the block database or querying block data, although the block database can use various schemes, it uses a unified IO interface for access.

[0054] ② State Database: Used to store the indexes generated during the execution of transactions in a block, along with the corresponding state data. It should be understood that during transaction execution, the corresponding smart contract is invoked to execute the transaction, which generates indexes and their corresponding state data.

[0055] In one implementation of the state database, this embodiment of the application employs grouping processing. That is, by grouping, the original single state database storing all indexes and their corresponding state data can be divided into multiple smaller state databases. These smaller state databases store partial indexes and their corresponding state data. In other words, the state databases in the storage system are obtained by grouping a large state database. Each group can be freely set by the object (user), or grouped according to smart contracts (or business types). For example, multiple smart contracts can be grouped into one state database, and the indexes generated when these smart contracts are invoked, along with their corresponding state data, will be stored in that state database. Alternatively, a single smart contract can be grouped into one state database, and the indexes generated when a single smart contract is invoked, along with their corresponding state data, will be stored in that state database. Of course, this embodiment of the application can directly provide multiple state databases instead of dividing a single state database, with each state database corresponding to one or more smart contracts.

[0056] It should be understood that the data in the state databases are isolated from each other and do not affect each other. This reduces the number of queries when querying state data in the state database, thereby improving query performance.

[0057] In another implementation, the volume of business data for each business system can be assessed, and the systems can be grouped according to the storage resources they occupy in the database. Each group's corresponding state database can store the corresponding volume of business data.

[0058] It should be understood that when a business process (which can be referred to as a transaction) is processed by a node, it calls the corresponding smart contract for processing. Therefore, the state database is the core for distinguishing business systems. That is to say, in this embodiment of the application, different business systems can use the same state database for data storage, or they can use different state databases for data storage. Each state database is used to store the business data of the corresponding business system. The type of state database corresponding to the business system is determined according to the business volume of the business system. The type of state database includes one or more of distributed databases, embedded databases, and cloud service databases.

[0059] The state database can be implemented in various ways, such as Figure 5 The diagram shown is a schematic representation of a state database provided in an embodiment of this application; Figure 5 In China, state databases include distributed databases, embedded databases, and cloud service databases (which can be simply referred to as such). Figure 5 This refers to one or more of the following: distributed databases (such as cloud databases). Distributed databases support sharding, meaning they can be divided into multiple sub-databases, such as... Figure 5 In this context, a distributed database can be sharded into three sub-databases (e.g., ...). Figure 5 (State databases 21, 22, ...). In one implementation, the type of state database corresponding to the business system is determined by the business volume of the business system. If the business volume of the business system is greater than the preset business volume, the type of state database corresponding to the business system includes a distributed database or a cloud service database; if the business volume of the business system is less than or equal to the preset business volume, the type of state database corresponding to the business system includes an embedded database. For example, for corporate transfer business, this type of business may involve a small number of accounts, and the data is basically account information, resulting in a smaller business volume, such as less than the preset business volume. In this case, the state database corresponding to the corporate transfer business system can use an embedded database. In contrast, for evidence storage business, all data may be stored in a database, so the business volume may be greater than the preset business volume. In this case, the state database of the evidence storage business system can use a distributed database or a scalable database such as a cloud service database.

[0060] ③ Metadatabase: Used to store metadata information for both the state database and the block database. This metadata information may include at least one of the following: access address, database instance, data storage type; additionally, the metadatabase also stores the contract names of smart contracts and the correspondence between state databases, etc. A database instance refers to the channel for accessing the database; all operations on the data in the database, including data definition, data query, data maintenance, and database operation control, are performed under the database instance. In one implementation, such as... Figure 3 In this implementation, the metadata database stores information including: database type, database access address, smart contracts, and the state database corresponding to the smart contracts, etc. For another implementation, please refer to [link / reference needed]. Figure 6 This is a schematic diagram of a metadata database provided in an embodiment of this application. Figure 6 In the metadata database, the content stored includes: database metadata information (such as access address, database data storage type, and database filtering method), where the filtering method can include either a Bloom filter or a Cuckoo filter; furthermore, in Figure 6 In addition, the metadata database also stores the smart contract's contract name (such as contract name A, contract name B) and the corresponding state database, as well as the metadata information of the corresponding state database.

[0061] ④ FilterDataDB: This database stores indexes within blocks and is primarily used for filtering access to these indexes. For example, when querying a specific index, the database can be queried to determine if the index exists. If it doesn't exist, there's no need to query other databases for the index and its corresponding status data. If it does exist, then other databases can be consulted for the index and its corresponding status data. By introducing a filter database, query results for the index can be obtained quickly, thus reducing query overhead. In one implementation, the filter database may use data structures such as Bloom filters or Cuckoo filters when storing indexes.

[0062] (2) Blockchain System 100

[0063] Each node 101 in the blockchain system corresponds to a storage system. For example... Figure 3 In this system, nodes can schedule data storage for each database. Furthermore, a cache can be deployed on node 101 to synchronize the content stored in the metadata database; specifically, the cache synchronizes the metadata information of each database stored in the metadata database. This allows metadata information to be retrieved directly from the cache, reducing retrieval time and improving access efficiency.

[0064] Node 101 can receive requests from the business system (such as business processing requests, query requests, etc.) and store the request as a transaction in the transaction pool. When executing a transaction, it can call the smart contract deployed on the blockchain to process the transaction, thereby generating a block to be stored. During the transaction execution process, a storage index and the corresponding state data are generated. Each node 101 can store the block data in the block to be stored into the block database according to the metadata information of the block database recorded in the metadata database, and store the storage index and the corresponding state data in the block to be stored into the corresponding state database according to the smart contract.

[0065] (3) The business system 103 can submit requests to the blockchain system 100 so that the nodes in the blockchain system 100 can process them. The business system 103 may include, but is not limited to: payment business system, transfer business system, resource exchange system, commodity trading system, etc., and this application embodiment does not limit it in any way.

[0066] It should be understood that the nodes in this application embodiment can be deployed on computer devices, which can be servers or terminals. The storage system involved in this application embodiment can be directly deployed on the nodes, or it can be deployed on other servers besides the nodes. The terminals can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc. The servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing 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, and big data and artificial intelligence platforms. Furthermore, the blockchain-based data processing flow provided in the application embodiments can be applied to the actual development of blockchain underlying software and can also be used as a means of external promotion.

[0067] In summary, the embodiments of this application, by introducing a general storage system, can differentiate between different business systems and address the performance impact caused by the difference in actual storage resources used by different business systems (i.e., different contracts), thereby improving the distributed storage performance of business data. For example, different business systems use different sizes of storage resources. As the amount of business data increases, the imbalance of business data can lead to performance impacts between businesses. For instance, a business that occupies relatively few storage resources (i.e., smart contracts) may experience a decrease in its execution performance due to other businesses that consume more storage resources (i.e., other smart contracts). The storage system provided by the embodiments of this application can determine the state database for storage according to the business type (or smart contract). This can reduce the problem of a business that occupies relatively few storage resources (i.e., smart contracts) experiencing a decrease in its execution performance (such as storage performance and query performance) due to other businesses that consume more storage resources (i.e., other smart contracts), thereby improving the distributed storage performance of blockchain data and increasing storage efficiency.

[0068] To facilitate understanding, the following section will describe the blockchain-based data processing flow provided in the embodiments of this application based on the above system. This data processing flow includes a data storage (i.e., writing) flow and a data query flow:

[0069] (1) Data storage process

[0070] ① Node 101 obtains the block to be stored and retrieves the metadata information of the block database already recorded in the metadata database. The block to be stored includes multiple indexes to be stored and the corresponding status data for those indexes. In one implementation, the node's cache synchronizes with the metadata information of the block database stored in the metadata database, and the node can retrieve the metadata information of the block database from the cache.

[0071] ②Based on the metadata information of the block database, store the block data of the block to be stored in the block database.

[0072] ③ Based on each index to be stored and the smart contract invoked when the corresponding state data of each index is generated, determine the target state database for storing each index to be stored and the corresponding state data. For example, the index to be stored includes key, key1 and the smart contract invoked when the corresponding state data of key1 is generated are contract 1, key2 and the smart contract invoked when the corresponding state data of key2 is generated are contract 2, state database 1 corresponds to smart contract 1, and state data 2 corresponds to smart contract 2; therefore, the target state database for storing key1 and the corresponding state data of key1 can be determined as state database 1, and the target state database for storing key2 and the corresponding state data of key2 is state database 2.

[0073] ④ Obtain the metadata information of the target state database already recorded in the metadata database, and based on the obtained metadata information of the target state database, store each index to be stored and the corresponding state data of each index to be stored into the corresponding target state database. For example, in the example above, obtain the metadata information of state database 1 already recorded in the database, and based on the metadata information of state database 1, store key1 and the corresponding state data of key1 into state database 1; obtain the metadata information of state database 2 already recorded in the database, and based on the metadata information of state database 2, store key2 and the corresponding state data of key2 into state database 2.

[0074] ⑤ Update the block height in the target state database based on the block to be stored.

[0075] In summary, the aforementioned storage system allows block data to be stored in a block database, while the indexes within blocks and their corresponding state data are stored in their respective state databases according to smart contracts. This addresses the issue of performance degradation in storage or querying caused by resource-intensive smart contracts being affected by resource-intensive smart contracts, thus improving blockchain data storage performance and efficiency to some extent. Furthermore, the introduction of a metadata database enhances the scalability of the storage system. This means that metadata information for the corresponding databases can be stored directly in the metadata database, eliminating the need to restart the blockchain system as required by writing metadata information to configuration files, making the system more flexible and convenient.

[0076] (2) Data query process:

[0077] ① The node receives a query request sent by the requesting object (such as the requester). The query request includes the index to be queried and is used to request the query of the status data corresponding to the index to be queried.

[0078] ② In response to the query request, the node obtains the metadata information of the filter database that has been recorded in the metadata database, and based on the metadata information of the filter database, queries the filter database to see if the index to be queried exists. If it exists, proceed to step ③; if it does not exist, proceed to step ⑤.

[0079] ③ Determine the query state database corresponding to the index to be queried from at least one state database, and obtain the metadata information of the query state database already recorded in the metadata database. Based on the metadata information of the query state database, query the state data corresponding to the index to be queried. The state data may include the state information of each account, such as balance, smart contract state, etc.

[0080] ④ Return the status data corresponding to the index to be queried to the request object.

[0081] ⑤ Return an empty message or a message indicating that the data does not exist to the requested object.

[0082] In summary, by filtering the indexes stored in the database during data queries, the query indexes can be accessed selectively, thus improving the efficiency of data retrieval.

[0083] It is understood that the system architecture diagrams described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0084] The following section will elaborate on the blockchain-based data processing method provided in the embodiments of this application.

[0085] Please see Figure 7 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The blockchain data processing method can be executed by nodes, each corresponding to a storage system. This storage system includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the corresponding state data. The metadata database records the metadata information of each state database and the metadata information of the block database. The blockchain-based data processing method includes at least steps S701-S705:

[0086] S701. Obtain the metadata information of the block database that has been recorded in the metadata database, and write the block data of the block to be stored into the block database based on the metadata information of the block database.

[0087] The metadata information includes at least one of the following: access address, database instance, data storage type (block data, state data, etc.), and filtering method (such as cuckoo filter, Bloom filter, etc.). It should be understood that the metadata information differs between different databases. For example, the metadata information of a block database may include the access address and data storage type (e.g., data storage type is block data). The metadata information of a state database includes the access address and data storage type (e.g., data storage type is state data).

[0088] In one implementation, the metadata information of the block database can be obtained from the metadata database. In another implementation, nodes deploy a cache, and the metadata information of the block database already recorded in the metadata database is synchronized to the cache, allowing for quick retrieval of the required database metadata information from the cache. Specifically, embodiments of this application provide a data synchronization scheme based on absolute timestamps, such as... Figure 8 The diagram shown is a schematic representation of a data synchronization process between a cache and a metadata database, provided in an embodiment of this application. Figure 8 In this process, a node can send a first subscription request to the metadata database. Specifically, the cache within the node can send the first subscription request to the metadata database. This first subscription request includes a first effective time (e.g., absolute time T1). This first subscription request declares that the metadata information of each database stored in the cache cannot be updated before the first effective time has elapsed. The metadata database receives the first subscription request sent by the node, returns the metadata information of each database it stores to the node, and simultaneously records the first effective time in the first subscription request. Correspondingly, the node receives the metadata information of each database returned by the metadata database based on the first subscription request, and synchronously stores the received metadata information of each database in the cache. By recording the first effective time, the metadata database signifies that the cache and the metadata database have negotiated that the metadata information stored in the cache will not be updated before the first effective time has elapsed. Here, "not updating" means that the content in the cache cannot be adjusted. For example, if the first effective date is XX year y month 30, the node receives metadata information from each database returned by the metadata database based on the first subscription request, and synchronously stores the received metadata information to the cache. If the content stored in the cache has not reached XX year y month 30, then the content stored in the cache will not be updated, that is, data adjustment is not allowed. It should be noted that the above data adjustment is an effective adjustment; adjustments can be made, but they will not take effect. The effectiveness is ultimately determined by the object (user); that is, the effectiveness is ultimately determined by the object, which can be understood as: the latest metadata information of the database that can ultimately be used is determined by the object.

[0089] In an optional implementation, in this embodiment of the application, an update can be initiated upon the arrival of the first effective time or periodically to update the metadata information in the cache, such as... Figure 8In this system, nodes can send a second subscription request to the metadata database. This second subscription request includes a second effective time (e.g., absolute time T2). Specifically, it can be a cache sending a second subscription request to the metadata database. The second subscription request is sent either when the first effective time arrives, or within a preset period but before the current time has exceeded the first effective time. In other words, there are two ways to trigger a second subscription request to the metadata database: Method 1: When the first effective time arrives, the cache cannot use the locally used metadata information after the first effective time, requiring a second subscription request to update the cache. Method 2: To improve access efficiency, the cache periodically synchronizes data with the metadata database, therefore sending a second subscription request within a preset period before the current time has reached the first effective time. The preset period can be set according to requirements, such as 5 minutes, 10 minutes, etc. After receiving the second subscription request, the metadata database can record the second effective time and retrieve the latest metadata information of each stored database, returning it to the node. Then, the node receives the latest metadata information of each database returned by the metadata database based on the second subscription request and updates its cache accordingly. The metadata information stored in the updated cache is not updated until the second effective time arrives. The first effective time is earlier than the second effective time.

[0090] When an object needs to update the metadata information of a database, for ease of understanding, let's take updating the metadata information of a block database as an example. The metadata information includes the access address. When an object needs to adjust the access address of a block database, it can send an adjustment request to the metadata database. This request requests adjustment of the block database's access address, and the metadata database can update the access address of that block database. At this time, the updated metadata information of the blockchain database in the metadata database includes the updated access address. If the cache update in the node is not complete, the block database can provide services in parallel based on both the original and updated access addresses. If the cache update is complete and the metadata database has sent a notification to the object, the block database provides services based on the updated access address. The notification notifies the object that the block database's access address update is complete and the original access address (i.e., the access address before the update) is offline. In other words, when an object adjusts the access address of a block database, it needs to update the access address of the block data in the cache and receive the notification from the metadata database before the original access address (the one before the update) is taken offline and services are no longer provided based on it.

[0091] S702. Obtain the index to be stored in the block to be stored. The index to be stored corresponds to state data.

[0092] The number of indices to be stored can be one or more, each index can be a key, and the corresponding state data can be the value associated with that key. It should be understood that during transaction execution, calling the smart contract generates the indices to be stored and the corresponding state data.

[0093] S703. Based on the smart contract corresponding to the block to be stored, determine the target state database from at least one state database for storing the index to be stored and the corresponding state data.

[0094] At least one smart contract is deployed on the blockchain. The smart contract corresponding to the block to be stored refers to the smart contract invoked during the process of generating the block during transaction execution. In one implementation, based on the smart contract corresponding to the block to be stored, a target state database for storing the index to be stored and the corresponding state data is determined from at least one state database, including the following steps s71-s73:

[0095] s71. Determine the smart contract invoked when the index to be stored in the block to be stored is generated.

[0096] s72. Obtain the mapping between smart contracts and the state database. In one implementation, the metadata database stores the mapping between smart contracts and the state database, for example... Figure 6 In this context, smart contract A (i.e., contract name A) corresponds to state database 1, and smart contract B (i.e., contract name B) corresponds to state database 2. The mapping between smart contracts and state databases can be obtained from the metadata database. Specifically, the cache synchronously contains the content stored in the metadata database, and the mapping between smart contracts and state databases can be obtained from the cache.

[0097] s73. Based on the smart contract invoked when the index to be stored in the block to be stored is generated, and the corresponding relationship, determine the target state database for storing the index to be stored and its corresponding state data. For example, if the smart contract invoked when the index to be stored 1 is generated is smart contract 1, then the state database corresponding to smart contract 1 can be determined as state database 1 based on smart contract 1 and the corresponding relationship. Therefore, state database 1 serves as the target state database for storing the index to be stored 1 and its corresponding state data.

[0098] When there are multiple indices to be stored, the target state database for storing the indices and their corresponding state data is determined based on the smart contracts invoked when the indices are generated in the blocks to be stored, and the corresponding relationships. This includes: grouping the multiple indices to be stored into multiple index subsets according to the smart contracts invoked when each index is generated, with each index subset corresponding to a smart contract; and determining the target state database for storing each index and its corresponding state data based on the corresponding relationships and the smart contracts corresponding to each index subset. Each index subset can be represented as a <smart contract, index subset> structure.

[0099] S704. Based on the metadata information of the target state database already recorded in the metadata database, store the index to be stored and the corresponding state data in the target state database.

[0100] In one implementation, there are multiple indexes to be stored, and correspondingly, there can be one or more target state databases. Based on the metadata information of the target state databases already recorded in the metadata database, the indexes to be stored and their corresponding state data are stored in the target state databases. This includes: retrieving the metadata information of each target state database from the cache, and storing the indexes to be stored and their corresponding state data in parallel into the respective target state databases based on the retrieved metadata information. Therefore, by storing the indexes to be stored and their corresponding state data in parallel into the respective target state databases, data storage can be achieved quickly, improving the storage performance and data storage efficiency of the storage system.

[0101] It should be understood that writing the block data of the block to be stored into the block database and storing the index and corresponding state data to be stored into the target state database can be performed simultaneously, or the block data of the block to be stored can be written into the block database first, and then the index and corresponding state data to be stored can be stored into the target state database; or the index and corresponding state data to be stored can be stored into the target state database first, and then the block data of the block to be stored can be written into the block database. This application embodiment does not limit this in any way.

[0102] S705. Update the block height in the target state database based on the block to be stored.

[0103] In one implementation, the block height of the block to be stored can be directly written into the target state database. In another implementation, the block height in the target state database can be replaced based on the block height of the block to be stored.

[0104] It should be understood that the blockchain system uses block height as the benchmark. Therefore, in this embodiment, data consistency between databases is not required. Block-related data can be recovered normally via WAL (Write-Ahead Logging) upon system restart. Thus, in this embodiment, it is necessary to ensure that the block height is written last. That is, the block height is written to the target state database only after all other data in the block to be stored (such as block data, indexes to be stored, and other data in the block to be stored) has been written. In other words, the block height is written last, and all data in the block depends on it. Specifically, the block height written to the target state database can be compared with the block height pre-written in the write-ahead log system. If they match, all indexes to be stored in the block to be stored and their corresponding state databases are stored in the corresponding target state database. If they do not match, the indexes to be stored in the block to be stored and their corresponding state data can be re-stored.

[0105] For example, if the block height of the block to be stored is 100, and the block height in the target state database is 100, and the block height in the WAL is also 100, then it means that the data in the block to be stored (i.e., the block data, the indexes in the block, and the state data corresponding to the indexes) has been completely stored in the corresponding database. Suppose the block height in the target state database is 99, and the block height in the WAL is 100, then it definitely means that there is data in the block to be stored corresponding to the block height of 100 that has not yet been written to the corresponding database. In this case, all the data generated in the block corresponding to the block height of 100 can be stored again to restore the storage of the block-related data normally.

[0106] Optionally, the storage system provided in this application embodiment may further include a filtering database, which is used to filter access to stored indexes. The metadata database also stores metadata information of the filtering database. The method provided in this application embodiment further includes: obtaining the metadata information of the filtering database already recorded in the metadata database. In one implementation, the metadata information of the filtering database already recorded in the metadata database is synchronized to a cache, and the node can obtain the metadata information of the filtering database from the cache. Then, based on the obtained metadata information of the filtering database, the index to be stored in the block to be stored is written to the filtering database. By writing the index to be stored to the filtering database, the index to be queried can be filtered and accessed through the filtering database during subsequent data queries, thereby improving query efficiency.

[0107] Please see Figure 9 This is a schematic diagram of a data storage process provided in an embodiment of this application. Figure 9In this process, nodes deploy a cache, and the index to be stored includes the key. The cache synchronizes metadata information from each database stored in the metadata database. This data storage process includes the following steps: s91. When a block commit is detected, the metadata information of the block database can be obtained from the cache. s92. Based on the metadata information of the block database, the block data of the block to be stored is written to the block database. s93. The metadata information of the filtering database is obtained from the cache. s94. Based on the metadata information of the filtering database, the key in the block to be stored is written to the filtering database. It should be understood that since not all blocks in the blockchain need to filter data, s93 and s94 are optional steps. s95. Obtain the set of all keys in the block to be stored, each key set including at least one key, and group all the key sets in the block to be stored according to the smart contract to generate a structure of <smart contract, index subset>. Specifically, the key set is grouped according to the smart contract called when the key is generated, generating a structure of <smart contract, index subset>. s96. For each smart contract's corresponding index subset, the target state database corresponding to the smart contract can be determined based on the correspondence between the smart contract and the state database. This target state database stores the index subset and the state data corresponding to each key within it. s97. Retrieve the metadata information of the target state database corresponding to the smart contract from the cache. s98. Based on the metadata information of the target state database, store the index subset corresponding to the smart contract and the state data corresponding to each key within it into the corresponding target state database. It should be understood that multiple smart contracts' corresponding index subsets and the state data corresponding to the keys within those index subsets can be stored in parallel into their respective target state databases. s99. Update the block height in the target state database according to the block height of the block to be stored.

[0108] In this embodiment, the blockchain node has a corresponding storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the corresponding state data. The metadata database records the metadata information of each state database and the metadata information of the block database. Therefore, this embodiment provides a completely new storage system for the node, allowing blockchain-related data (such as block data, state data, etc.) to be stored separately. This avoids the performance issues caused by storing all blockchain data in a single database and improves the efficiency of blockchain data storage. The process involves: obtaining the metadata information of the block database already recorded in the metadata database; writing the block data of the block to be stored into the block database based on the metadata information; obtaining the index to be stored in the block to be stored, which corresponds to state data; determining a target state database from at least one state database to store the index to be stored and its corresponding state data based on the smart contract corresponding to the block to be stored; storing the index to be stored and its corresponding state data in the target state database based on the metadata information of the target state database already recorded in the metadata database; and updating the block height in the target state database based on the block to be stored. As can be seen, this embodiment can obtain metadata information of the corresponding database recorded in the metadata database, thereby storing block data and state data in the block into the corresponding databases respectively. This avoids the problem of low storage efficiency caused by storing data in a single database simultaneously, thus improving the efficiency of blockchain data processing. Furthermore, this embodiment selects a state database for state data storage according to the smart contract. This allows for differentiated storage of state data corresponding to each smart contract, reducing the impact on data storage performance caused by the different storage resources occupied by indexes generated by smart contracts and the corresponding state resources, and further improving the efficiency of blockchain data processing.

[0109] Please see Figure 10 This is a flowchart illustrating another blockchain-based data processing method provided in an embodiment of this application. This blockchain-based data processing method can be executed by a node and may include steps S1001-S1004:

[0110] S1001. Receive a query request initiated by the requesting object. The query request includes the index to be queried.

[0111] The index to be queried is an index bound to the smart contracts deployed on the blockchain. In other words, the index to be queried can be an index generated when the smart contract is called, or an index strongly related to the business logic. For example, in a money transfer transaction, if there's an account named "zhangsan" and a smart contract is called to transfer money to that account, resulting in the account having 10,000, then the index to be queried would be the contract name + "zhangsan". Alternatively, the index to be queried can be an index related to blocks in the blockchain. In this case, the index to be queried can be understood as a general index, which refers to the indexes of the blockchain system, such as block height. The index to be queried could be "blockheight," which is a general index unrelated to the smart contract.

[0112] S1002. In response to the query request, determine the query status database containing the index to be queried from at least one status database.

[0113] In one implementation, determining the query state database containing the index to be queried from at least one state database may include: obtaining the prefix of the index to be queried; if the prefix includes a contract name, then in response to a query request, searching for the state database corresponding to the contract name from at least one state database, and using the found state database corresponding to the contract name as the query state database containing the index to be queried. It should be understood that the cache stores the content stored in the metadata database, and searching for the state database corresponding to the contract name from at least one state database may include obtaining the correspondence between smart contracts and state databases from the cache, and determining the state database corresponding to the contract name based on the correspondence. If the prefix of the index to be queried does not include a contract name, it means that the index to be queried is a general index, then the database containing the index to be queried is determined to be a block database, and the block data corresponding to the index to be queried can be obtained from the block database.

[0114] Optionally, the storage system also includes a filtering database, which is used to filter access to the stored indexes. The node can obtain the metadata information of the filtering database that has been recorded in the metadata database, and determine whether the index to be queried exists in the filtering database based on the metadata information of the filtering database. If the index to be queried exists in the filtering database, then S1003 is executed; if the index to be queried does not exist in the filtering database, then a prompt message is output to indicate that the index to be queried does not exist in the database.

[0115] S1003. Obtain the metadata information of the query status database already recorded in the metadata database, and retrieve the status data corresponding to the index to be queried from the query status database based on the metadata information of the query status database. In one implementation, the metadata information of the query status database can be retrieved from the cache.

[0116] S1004. Return the status data corresponding to the index to be queried to the request object.

[0117] For easier understanding, please refer to Figure 11 This is a schematic diagram illustrating a specific data query process in an embodiment of this application. Figure 11 In this process, metadata information from each database recorded in the metadata database is synchronized to the node's cache. The index to be queried includes the key to be queried, and the prefix of the key to be queried includes the contract name. The data query process may include: s1101, when a key needs to be queried, the node can obtain a query request, which includes the key to be queried; s1102, obtain the metadata information of the filter database from the cache; s1103, based on the metadata information of the filter database, determine whether the key to be queried exists in the filter database. If the key to be queried exists in the filter database, proceed to step s1104; otherwise, proceed to step s1105. If the key to be queried does not exist in the database, proceed to step s1107; s1104: Determine the query status database corresponding to the key to be queried from at least one status database, and retrieve the metadata information of the query status database corresponding to the key to be queried from the cache; s1105: Based on the metadata information of the query status database, retrieve the status data (i.e., value) corresponding to the key to be queried from the query status database; s1106: Return the status data corresponding to the key to be queried to the request object; s1107: Return a prompt message to the request object, which indicates that the key to be queried does not exist.

[0118] In this embodiment, a query request initiated by a requesting object is received. The query request includes an index to be queried. In response to the query request, the system determines the query status database where the index to be queried is located from at least one status database. Metadata information of the query status database, already recorded in the metadata database, is obtained. Based on the metadata information of the query status database, the system retrieves the status data corresponding to the index to be queried from the query status database. The system returns the status data corresponding to the index to be queried to the requesting object. By using the metadata information of the query status database already recorded in the metadata database, data query efficiency can be improved. Furthermore, during data querying, it is possible to first check whether the index to be stored is in the filter database. If the index to be stored exists in the filter database, then the system queries the corresponding status database for the index to be queried. This further improves data query efficiency.

[0119] The following section will describe the blockchain-based data processing device provided in the embodiments of this application.

[0120] Please see Figure 12 , Figure 12This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. The blockchain-based data processing device can be a computer program (including program code) within a computer device; for example, it can be application software within a computer device. The blockchain-based data processing device can be used to execute... Figure 7 or Figure 10 The illustrated method embodiments include some or all of the steps. Each blockchain node corresponds to a storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the corresponding state data. The metadata database records the metadata information of each state database and the metadata information of the block database. Please refer to [link to relevant documentation]. Figure 12 The blockchain-based data processing device includes the following units:

[0121] The acquisition unit 1201 is used to acquire metadata information of the block database that has been recorded in the metadata database;

[0122] The processing unit 1202 is used to write the block data of the obtained block to be stored into the block database based on the metadata information of the block database.

[0123] The acquisition unit 1201 is also used to acquire the index to be stored in the block to be stored, and the index to be stored corresponds to state data;

[0124] The processing unit 1202 is further configured to determine, based on the smart contract corresponding to the block to be stored, a target state database for storing the index to be stored and the corresponding state data from at least one state database.

[0125] The processing unit 1202 is also used to store the index to be stored and the corresponding state data into the target state database based on the metadata information of the target state database already recorded in the metadata database, and to update the block height in the target state database based on the block to be stored.

[0126] In one implementation, the storage system further includes a filtering database, and the metadata database stores metadata information of the filtering database. The filtering database is used for filtered access to the stored indexes; the processing unit 1202 is further used for:

[0127] Retrieve metadata information of the filter database that has been recorded in the metadata database;

[0128] Based on the metadata information of the filter database, the index to be stored in the block to be stored is written to the filter database.

[0129] In one implementation, when the processing unit 1202 determines the target state database for storing the index to be stored and the corresponding state data from at least one state database according to the smart contract corresponding to the block to be stored, it may specifically be used to:

[0130] Determine the smart contract invoked when the index to be stored in the block to be stored is generated;

[0131] Obtain the mapping between smart contracts and the state database;

[0132] Based on the smart contract invoked when the index to be stored in the block to be stored is generated, and the corresponding relationship, determine the target state database for storing the index to be stored and the state data corresponding to the index to be stored.

[0133] In one implementation, there are multiple indexes to be stored. When the processing unit 1202 determines the target state database for storing the indexes to be stored and their corresponding state data based on the smart contracts invoked when the indexes to be stored are generated in the block to be stored, and the corresponding relationships, it can specifically be used for:

[0134] Based on the smart contract invoked when each index to be stored in the block to be stored is generated, multiple indexes to be stored are grouped to obtain multiple index subsets, and each index subset corresponds to a smart contract;

[0135] Based on the correspondence and the smart contract corresponding to each index subset, determine the target state database for storing each index to be stored and the corresponding state data of each index to be stored.

[0136] In one implementation, the node is equipped with a cache, and the processing unit 1202 is further used for:

[0137] Send the first subscription request to the metadata database. The first subscription request includes the first effective time.

[0138] Receive metadata information from each database returned by the metadata database based on the first subscription request;

[0139] The received metadata information from each database is synchronously stored in the cache; the metadata information stored in the cache is not updated before the first effective time.

[0140] In one implementation, there are multiple indexes to be stored and multiple target state databases. When processing unit 1202 stores the indexes to be stored and their corresponding state data in the target state database based on the metadata information of the target state database already recorded in the metadata database, it can be specifically used for:

[0141] Retrieve metadata information for each target state database from the cache;

[0142] Based on the metadata information of each target state database obtained, each index to be stored and the corresponding state data of each index to be stored are stored in parallel to the corresponding target state database.

[0143] In one implementation, the processing unit 1202 is further configured to:

[0144] Send a second subscription request to the metadata database. The second subscription request includes a second effective time. The second subscription request is sent when the first effective time arrives, or the second subscription request is sent within a preset period and before the current time exceeds the first effective time.

[0145] Receive the latest metadata information of each database returned by the metadata database based on the second subscription request;

[0146] The cache is updated based on the latest metadata information received from each database; however, the metadata information stored in the updated cache is not updated until the second effective time has elapsed.

[0147] In one implementation, the metadata information includes the access address, and when the access address of the block database is updated, the updated metadata information of the block database includes the updated access address.

[0148] If the cache update is not complete, the block database will provide services in parallel based on the access address before the update and the access address after the update;

[0149] If the cache update is complete and the metadata database has sent a notification message to the object, the block database will provide services based on the updated access address; the notification message is used to notify the object that the block database address update has been completed.

[0150] In one implementation, the processing unit 1202 is further configured to:

[0151] Receive a query request initiated by a requesting object. The query request includes an index to be queried. The index to be queried is either an index that is bound to a smart contract deployed on the blockchain or an index that is related to a block in the blockchain.

[0152] In response to a query request, determine the query status database containing the index to be queried from at least one status database;

[0153] Obtain the metadata information of the query status database that has been recorded in the metadata database, and obtain the status data corresponding to the index to be queried from the query status database based on the metadata information of the query status database;

[0154] Returns the status data corresponding to the index to be queried to the request object.

[0155] In one implementation, the storage system further includes a filtering database for filtering access to stored indexes, and the processing unit is also used for:

[0156] Retrieve metadata information of the filter database that has been recorded in the metadata database;

[0157] Based on the metadata information of the filter database, determine whether the index to be queried exists in the filter database;

[0158] If the index to be queried exists in the filter database, then in response to the query request, the step of determining the query state database containing the index to be queried from at least one state database is performed.

[0159] In one implementation, each state database is used to store the business data of the corresponding business system. The type of state database corresponding to the business system is determined according to the business volume of the business system. The type of state database includes one or more of distributed database, embedded database, and cloud service database.

[0160] If the business volume of the business system is greater than the preset business volume, the type of the state database corresponding to the business system includes a distributed database or a cloud service database; if the business volume of the business system is less than or equal to the preset business volume, the type of the state database corresponding to the business system includes an embedded database.

[0161] In this embodiment, the blockchain node has a corresponding storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the corresponding state data. The metadata database records the metadata information of each state database and the metadata information of the block database. Therefore, this embodiment provides a completely new storage system for the node, allowing for the separate storage and management of blockchain-related data (such as block data, state data, etc.). This avoids the performance issues associated with storing all blockchain data in a single database and improves the efficiency of blockchain data storage. The process involves: acquiring metadata information of the block database recorded in the metadata database; writing the block data of the block to be stored into the block database based on the metadata information of the block database; acquiring the index to be stored in the block to be stored, which corresponds to state data; determining a target state database for storing the index to be stored and the corresponding state data from at least one state database according to the smart contract corresponding to the block to be stored; deploying at least one smart contract on the blockchain; storing the index to be stored and the corresponding state data in the target state database based on the metadata information of the target state database recorded in the metadata database; and updating the block height in the target state database based on the block to be stored. As can be seen, this embodiment can acquire metadata information of the corresponding database recorded in the metadata database, thereby storing the block data and the state data in the block into the corresponding database respectively. This avoids the problem of low storage efficiency caused by storing data in a single database simultaneously, and improves the data storage efficiency and performance of the blockchain. Furthermore, in this embodiment, the state database is selected according to the smart contract for state data storage. This allows for the differentiated storage of state data corresponding to each smart contract, which can reduce the impact on data storage performance caused by the different storage resources occupied by the indexes generated by the smart contracts and the state resources corresponding to the indexes. It also improves the storage efficiency and performance of blockchain data.

[0162] The computer device provided in the embodiments of this application will be described in detail below.

[0163] Furthermore, this application also provides a schematic diagram of the structure of a computer device, which can be found in [reference needed]. Figure 13 The computer device may include a processor 1301, an input device 1302, an output device 1303, and a memory 1304. The processor 1301, input device 1302, output device 1303, and memory 1304 are connected via a bus. The memory 1304 stores computer programs, including program instructions, and the processor 1301 executes the program instructions stored in the memory 1304.

[0164] In one embodiment, the node where the blockchain resides has a corresponding storage system. The storage system includes a block database, at least one state database, and a metadata database. Each state database is used to store the indexes generated in the blocks and the state data corresponding to the indexes. The metadata database is used to record the metadata information of each state database and the metadata information of the block database. The processor 1301 executes the following operations by running program instructions in the memory 1304:

[0165] Obtain the metadata information of the block database that has been recorded in the metadata database, and write the block data of the block to be stored into the block database based on the metadata information of the block database;

[0166] Retrieve the index to be stored from the block to be stored; the index to be stored corresponds to state data.

[0167] Based on the smart contract corresponding to the block to be stored, determine the target state database from at least one state database to store the index to be stored and the corresponding state data.

[0168] Based on the metadata information of the target state database already recorded in the metadata database, the index to be stored and the corresponding state data are stored in the target state database, and the block height in the target state database is updated based on the block to be stored.

[0169] In one implementation, the storage system further includes a filtering database, which stores metadata information about the filtering database. The filtering database is used to filter access to the stored indexes. The processor 1301 can also perform the following operations:

[0170] Retrieve metadata information of the filter database that has been recorded in the metadata database;

[0171] Based on the metadata information of the filter database, the index to be stored in the block to be stored is written to the filter database.

[0172] In one implementation, when the processor 1301 determines the target state database for storing the index to be stored and the corresponding state data from at least one state database according to the smart contract corresponding to the block to be stored, it may specifically perform the following operations:

[0173] Determine the smart contract invoked when the index to be stored in the block to be stored is generated;

[0174] Obtain the mapping between smart contracts and the state database;

[0175] Based on the smart contract invoked when the index to be stored in the block to be stored is generated, and the corresponding relationship, determine the target state database for storing the index to be stored and the state data corresponding to the index to be stored.

[0176] In one implementation, there are multiple indexes to be stored. When the processor 1301 determines the target state database for storing the indexes to be stored and their corresponding state data based on the smart contract invoked when the indexes to be stored in the block to be stored are generated, and the corresponding relationship, it may specifically perform the following operations:

[0177] Based on the smart contract invoked when each index to be stored in the block to be stored is generated, multiple indexes to be stored are grouped to obtain multiple index subsets, and each index subset corresponds to a smart contract;

[0178] Based on the correspondence and the smart contract corresponding to each index subset, determine the target state database for storing each index to be stored and the corresponding state data of each index to be stored.

[0179] In one implementation, the node is equipped with a cache, processor 1301, and can also perform the following operations:

[0180] Send the first subscription request to the metadata database. The first subscription request includes the first effective time.

[0181] Receive metadata information from each database returned by the metadata database based on the first subscription request;

[0182] The received metadata information from each database is synchronously stored in the cache; the metadata information stored in the cache is not updated before the first effective time.

[0183] In one implementation, there are multiple indexes to be stored and multiple target state databases. When the processor 1301 stores the indexes to be stored and their corresponding state data in the target state database based on the metadata information of the target state database already recorded in the metadata database, it can specifically perform the following operations:

[0184] Retrieve metadata information for each target state database from the cache;

[0185] Based on the metadata information of each target state database obtained, each index to be stored and the corresponding state data of each index to be stored are stored in parallel to the corresponding target state database.

[0186] In one implementation, processor 1301 may also perform the following operations:

[0187] Send a second subscription request to the metadata database. The second subscription request includes a second effective time. The second subscription request is sent when the first effective time arrives, or the second subscription request is sent within a preset period and before the current time exceeds the first effective time.

[0188] Receive the latest metadata information of each database returned by the metadata database based on the second subscription request;

[0189] The cache is updated based on the latest metadata information received from each database; however, the metadata information stored in the updated cache is not updated until the second effective time has elapsed.

[0190] In one implementation, the metadata information includes the access address, and when the access address of the block database is updated, the updated metadata information of the block database includes the updated access address.

[0191] If the cache update is not complete, the block database will provide services in parallel based on the access address before the update and the access address after the update;

[0192] If the cache update is complete and the metadata database has sent a notification message to the object, the block database provides services based on the updated access address; the notification message is used to notify the object that the block database address update has been completed.

[0193] In one implementation, processor 1301 may also perform the following operations:

[0194] Receive a query request initiated by a requesting object. The query request includes an index to be queried. The index to be queried is either an index that is bound to a smart contract deployed on the blockchain or an index that is related to a block in the blockchain.

[0195] In response to a query request, determine the query status database containing the index to be queried from at least one status database;

[0196] Obtain the metadata information of the query status database that has been recorded in the metadata database, and obtain the status data corresponding to the index to be queried from the query status database based on the metadata information of the query status database;

[0197] Returns the status data corresponding to the index to be queried to the request object.

[0198] In one implementation, the storage system further includes a filtering database for filtering access to the stored indexes, and the processor 1301 can also perform the following operations:

[0199] Retrieve metadata information of the filter database that has been recorded in the metadata database;

[0200] Based on the metadata information of the filter database, determine whether the index to be queried exists in the filter database;

[0201] If the index to be queried exists in the filter database, then in response to the query request, the step of determining the query state database containing the index to be queried from at least one state database is performed.

[0202] In one implementation, each state database is used to store the business data of the corresponding business system. The type of state database corresponding to the business system is determined according to the business volume of the business system. The type of state database includes one or more of distributed database, embedded database, and cloud service database.

[0203] If the business volume of the business system is greater than the preset business volume, the type of the state database corresponding to the business system includes a distributed database or a cloud service database; if the business volume of the business system is less than or equal to the preset business volume, the type of the state database corresponding to the business system includes an embedded database.

[0204] In this embodiment, the blockchain node has a corresponding storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the corresponding state data. The metadata database records the metadata information of each state database and the metadata information of the block database. Therefore, this embodiment provides a completely new storage system for the node, allowing for the separate storage and management of blockchain-related data (such as block data, state data, etc.). This avoids the performance issues associated with storing all blockchain data in a single database and improves the efficiency of blockchain data storage. The process involves: acquiring metadata information of the block database recorded in the metadata database; writing the block data of the block to be stored into the block database based on the metadata information of the block database; acquiring the index to be stored in the block to be stored, which corresponds to state data; determining a target state database for storing the index to be stored and the corresponding state data from at least one state database according to the smart contract corresponding to the block to be stored; deploying at least one smart contract on the blockchain; storing the index to be stored and the corresponding state data in the target state database based on the metadata information of the target state database recorded in the metadata database; and updating the block height in the target state database based on the block to be stored. As can be seen, this embodiment can acquire metadata information of the corresponding database recorded in the metadata database, thereby storing the block data and the state data in the block into the corresponding database respectively. This avoids the problem of low storage efficiency caused by storing data in a single database simultaneously, and improves the data storage efficiency and performance of the blockchain. Furthermore, in this embodiment, the state database is selected according to the smart contract for state data storage. This allows for the differentiated storage of state data corresponding to each smart contract, which can reduce the impact on data storage performance caused by the different storage resources occupied by the indexes generated by the smart contracts and the state resources corresponding to the indexes. It also improves the storage efficiency and performance of blockchain data.

[0205] In this application, the term "unit" refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more units. Furthermore, each unit can be part of an overall unit that includes the functionality of that unit.

[0206] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program, which includes program instructions. When a processor executes these program instructions, it can execute the aforementioned... Figure 7 orFigure 10 The methods described in the corresponding embodiments are therefore not repeated here. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application. As an example, program instructions may be deployed on a computer device, executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network.

[0207] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, enabling the computer device to perform the aforementioned... Figure 7 or Figure 10 The methods described in the corresponding embodiments are therefore not repeated here.

[0208] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0209] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on blockchain, characterized in that, The blockchain node corresponds to a storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the state data corresponding to those indexes. The metadata database records the metadata information of each state database and the metadata information of the block database. The method includes: Obtain the metadata information of the block database that has been recorded in the metadata database, and write the block data of the block to be stored into the block database based on the metadata information of the block database; Obtain the index to be stored in the block to be stored, where the index corresponds to state data; Based on the smart contract corresponding to the block to be stored, a target state database for storing the index to be stored and the corresponding state data is determined from at least one state database. Based on the metadata information of the target state database already recorded in the metadata database, the index to be stored and the corresponding state data are stored in the target state database, and the block height in the target state database is updated based on the block to be stored.

2. The method as described in claim 1, characterized in that, The storage system further includes a filtering database, and the metadata database stores metadata information of the filtering database. The filtering database is used for filtered access to the stored indexes; the method further includes: Obtain the metadata information of the filtering database that has been recorded in the metadata database; Based on the metadata information of the filtering database, the index to be stored in the block to be stored is written to the filtering database.

3. The method as described in claim 1, characterized in that, The step of determining a target state database for storing the index to be stored and the corresponding state data from at least one state database according to the smart contract corresponding to the block to be stored includes: Determine the smart contract invoked when the index to be stored in the block to be stored is generated; Obtain the mapping between smart contracts and the state database; Based on the smart contract invoked when the index to be stored in the block to be stored is generated, and the corresponding relationship, a target state database is determined for storing the index to be stored and the state data corresponding to the index to be stored.

4. The method as described in claim 3, characterized in that, The number of indexes to be stored is multiple. The step of determining a target state database for storing the indexes to be stored and their corresponding state data, based on the smart contract invoked when the indexes to be stored are generated in the block to be stored and the corresponding relationship, includes: Based on the smart contract invoked when each index to be stored in the block to be stored is generated, multiple indexes to be stored are grouped to obtain multiple index subsets, and each index subset corresponds to a smart contract; Based on the correspondence and the smart contract corresponding to each index subset, a target state database is determined for storing each index to be stored and the corresponding state data of each index to be stored.

5. The method as described in claim 1, characterized in that, The node is equipped with a cache, and the method further includes: Send a first subscription request to the metadata database, wherein the first subscription request includes a first effective time; Receive metadata information of each database returned by the metadata database based on the first subscription request; The received metadata information from each database is synchronously stored in the cache; wherein the metadata information stored in the cache is not updated before the first effective time.

6. The method as described in claim 5, characterized in that, The number of indexes to be stored is multiple, and the number of target state databases is multiple. The step of storing the indexes to be stored and their corresponding state data into the target state database based on the metadata information of the target state database already recorded in the metadata database includes: Obtain metadata information for each target state database from the cache; Based on the metadata information of each target state database obtained, each index to be stored and the corresponding state data of each index to be stored are stored in parallel to the corresponding target state database.

7. The method as described in claim 5, characterized in that, The method further includes: Send a second subscription request to the metadata database, the second subscription request including a second effective time; wherein, the second subscription request is sent when the first effective time arrives, or the second subscription request is sent within a preset period and before the current time exceeds the first effective time; Receive the latest metadata information of each database returned by the metadata database based on the second subscription request; The cache is updated based on the latest metadata information received from each database; wherein the metadata information stored in the updated cache is not updated before the second effective time.

8. The method as described in claim 7, characterized in that, The metadata information includes the access address. When the access address of the block database is updated, the updated metadata information of the block database includes the updated access address. If the cache update is not completed, the block database provides services in parallel based on the access address before the update and the access address after the update; If the cache update is complete and the metadata database has sent a notification message to the object, the block database provides services based on the updated access address; wherein, the notification message is used to notify the object that the address update of the block database has been completed.

9. The method as described in claim 1, characterized in that, The method further includes: The system receives a query request initiated by a requesting object, the query request including an index to be queried; wherein the index to be queried is an index bound to a smart contract deployed on the blockchain or an index related to a block in the blockchain; In response to the query request, the query status database containing the index to be queried is determined from the at least one status database; Obtain the metadata information of the query status database that has been recorded in the metadata database, and obtain the status data corresponding to the index to be queried from the query status database based on the metadata information of the query status database; Return the status data corresponding to the index to be queried to the requesting object.

10. The method as described in claim 9, characterized in that, The storage system further includes a filtering database, which is used to filter access to the stored indexes. The method further includes: Obtain the metadata information of the filtering database that has been recorded in the metadata database; Based on the metadata information of the filtering database, determine whether the index to be queried exists in the filtering database; If the index to be queried exists in the filter database, then in response to the query request, the step of determining the query status database in which the index to be queried is located from the at least one status database is performed.

11. The method as described in claim 1, characterized in that, Each status database is used to store business data of the corresponding business system. The type of status database corresponding to the business system is determined according to the business volume of the business system. The type of status database includes one or more of distributed database, embedded database, and cloud service database. Wherein, if the business volume of the business system is greater than the preset business volume, the type of the state database corresponding to the business system includes a distributed database or a cloud service database; if the business volume of the business system is less than or equal to the preset business volume, the type of the state database corresponding to the business system includes an embedded database.

12. A data processing device based on blockchain, characterized in that, The blockchain node corresponds to a storage system, which includes a block database, at least one state database, and a metadata database. Each state database stores the indexes generated in the blocks and the state data corresponding to those indexes. The metadata database records the metadata information of each state database and the metadata information of the block database. The device includes: The acquisition unit is used to acquire metadata information of the block database that has been recorded in the metadata database; The processing unit is used to write the block data of the acquired block to be stored into the block database based on the metadata information of the block database; The acquisition unit is further configured to acquire the index to be stored in the block to be stored, and the index to be stored corresponds to state data; The processing unit is further configured to determine, based on the smart contract corresponding to the block to be stored, a target state database for storing the index to be stored and the corresponding state data from at least one state database. The processing unit is further configured to store the index to be stored and the corresponding state data into the target state database based on the metadata information of the target state database already recorded in the metadata database, and update the block height in the target state database based on the block to be stored.

13. A computer device, characterized in that, include: A processor is used to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, performs the blockchain-based data processing method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, performs the blockchain-based data processing method according to any one of claims 1-11.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the blockchain-based data processing method according to any one of claims 1-11.

Images