Data processing method and apparatus in a blockchain system

Abstract

A data processing method and apparatus in a blockchain system. A service node executing the method includes multiple filtering components and corresponding multiple storage files. The filtering components support querying whether on-chain data of a desired account exists in the corresponding storage file. Any i-th storage file includes on-chain data with multiple first accounts as keys. Any j-th first account is an account involved in transactions within several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions specifically involving the j-th first account in the several first blocks and the block numbers of their respective blocks. The method includes: determining two storage files corresponding to the same target filtering component, the two storage files including on-chain data with the same second account as a key; merging the two files into a third storage file; and reconfiguring the target filtering component to correspond to the third storage file.

Description

Technical Field

[0001] The embodiments in this specification pertain to the field of blockchain, and particularly relate to a data processing method and apparatus in a blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a data processing method and apparatus in a blockchain system.

[0004] Firstly, a data processing method is provided in a blockchain system. This method is executed by a service node, which includes multiple filtering components and corresponding multiple storage files. The filtering components support querying whether on-chain data of a desired account exists in the corresponding storage files. Any i-th storage file includes on-chain data of multiple first accounts using multiple first accounts as keys. Any j-th first account is an account involved in transactions within several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions involving the j-th first account in the several first blocks and the block numbers of their respective blocks. The method includes: determining a first storage file and a second storage file from the multiple storage files, wherein the first storage file and the second storage file correspond to the same target filtering component and include on-chain data using the same second account as a key; merging the first storage file and the second storage file into a third storage file; and reconfiguring the target filtering component to correspond to the third storage file.

[0005] Secondly, a data processing device is provided in a blockchain system. The device is deployed in a service node, which includes multiple filtering components and corresponding multiple storage files. The filtering components support querying whether on-chain data of a desired account exists in the corresponding storage file. Any i-th storage file includes on-chain data of multiple first accounts using multiple first accounts as keys. Any j-th first account is an account involved in transactions within several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions involving the j-th first account in the several first blocks and the block numbers of their respective blocks. The device includes: a merging and determining unit configured to determine a first storage file and a second storage file from the multiple storage files, wherein the first storage file and the second storage file correspond to the same target filtering component and include on-chain data using the same second account as a key; a merging and processing unit configured to merge the first storage file and the second storage file into a third storage file; and a configuration processing unit configured to configure the target filtering component as a filtering component corresponding to the third storage file.

[0006] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0007] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0008] In the embodiments of this specification, the service node includes multiple filtering components and corresponding multiple storage files. The filtering components are used to support querying whether the on-chain data of the desired account exists in the corresponding storage file. Any i-th storage file includes on-chain data with multiple first accounts as keys, and any j-th first account is an account involved in transactions in several first blocks corresponding to the i-th storage file; the on-chain data of the j-th first account includes several first transactions involving the j-th first account in the several first blocks and the block number of the block to which each belongs. When two storage files corresponding to the same filtering component include on-chain data with the same second account as a key, the two storage files can be merged, and the filters corresponding to the two storage files can be reconfigured to filter components corresponding to the merged storage file. In this way, for the query request initiated by the data requester to query the on-chain data of a certain account in certain blocks in the subsequent process, the frequency of the service node querying the corresponding storage file to see if the on-chain data of the account exists through the filtering component during the response to the query request can be reduced as much as possible, and the frequency of querying the on-chain data of the account from multiple storage files can be reduced as much as possible. This helps the service node to complete the response to the data query request more quickly and saves the storage space of the service node. Attached Figure Description

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

[0010] Figure 1 This is an architecture diagram of a blockchain system provided in the embodiments of this specification;

[0011] Figure 2 This is one of the flowcharts for a data processing method in a blockchain system provided in the embodiments of this specification;

[0012] Figure 3 This is a schematic diagram illustrating the blockchain data storage provided as an example in the embodiments of this specification;

[0013] Figure 4 This is a schematic diagram of the structure of the filtering component provided as an example in the embodiments of this specification;

[0014] Figure 5 This is a second flowchart of a data processing method in a blockchain system provided in the embodiments of this specification;

[0015] Figure 6 This is the third flowchart of a data processing method in a blockchain system provided in the embodiments of this specification.

[0016] Figure 7 This is a schematic diagram illustrating the merging of two files as an example provided in the embodiments of this specification;

[0017] Figure 8 This is the fourth flowchart of a data processing method in a blockchain system provided in the embodiments of this specification;

[0018] Figure 9 This is a schematic diagram of the structure of a data processing device in a blockchain system provided in the embodiments of this specification. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0020] Figure 1 This is an exemplary architecture diagram of a blockchain system provided in the embodiments of this specification. The blockchain system may include N blockchain nodes, wherein... Figure 1 The example shows eight blockchain nodes, numbered 1 through 8. The connections between the nodes schematically represent P2P (Peer-to-Peer) connections, such as Transmission Control Protocol (TCP) connections, which are used to support the transfer of data between different nodes.

[0021] In a blockchain system, the system data that needs to be persistently stored can be divided into two parts: block data and state data.

[0022] Block data includes one or more blocks in ascending order of block height (or block number). A single block may include a block header and a block body. The block header may include the previous block's block hash (or parent hash), timestamp, block number (BlockNum), state root hash (State_Root), transaction root hash (Transaction_Root), and receipt root hash (Receipt_Root), etc. The block body may include a set of transactions and a set of receipts.

[0023] A transaction in a blockchain system refers to a unit of task executed and recorded within the blockchain system. A single transaction typically includes a From field, a To field, and a Data field. The From field includes the account that initiated the transaction, and the To field may include another account involved in the transaction.

[0024] For any k-th block, based on the state data with block height (or version) k-1, execute multiple transactions in the transaction set belonging to the k-th block, arranged in sequence, and obtain the execution results of these transactions. Then, update the state data with block height k-1 based on the execution results of these transactions to obtain the state data with block height k.

[0025] Blockchain technology has been widely adopted; however, it has also been accompanied by numerous illegal activities based on it, leading to a growing demand for regulatory oversight of data within blockchain systems. Furthermore, some data users may wish to utilize data from blockchain systems on demand. Based on these needs, queries typically target accounts registered in the blockchain system, retrieving on-chain data for those accounts generated within a specific time interval or block. This data can then be used for modeling, analysis, or other processing to achieve specific objectives.

[0026] Figure 2 This is one of the flowcharts for a data processing method in a blockchain system provided in the embodiments of this specification. The method can be executed by a service node, such as a blockchain node in the blockchain system. The method exemplarily describes the process of storing and processing multiple transactions in a second block. This second block can be a newly generated block by the blockchain node, or it can be a block queried from the blockchain system by other service nodes besides the blockchain node.

[0027] See Figure 2 As shown, the method may include, but is not limited to, some or all of the following steps S21 to S25.

[0028] Step S21: Identify multiple third accounts involved in multiple transactions in the second block.

[0029] For a single transaction, only the accounts included in the From field of the transaction can be identified as third accounts involved in the transaction, or both accounts included in the From and To fields of the transaction can be identified as third accounts involved in the transaction. For example, if block V3 includes transactions Tx31 and Tx32 initiated by account Node1, where transaction Tx31 is used to transfer digital resources to account Node2 and transaction Tx32 is used to transfer digital resources to account Node3, then accounts Node1, Node2, and Node3 are the multiple third accounts involved in transactions Tx31 and Tx32.

[0030] Step S23: For any m-th third account among multiple third accounts, store the on-chain data of the m-th third account in the storage file corresponding to the second block, using the m-th third account as the key. The on-chain data of the m-th third account includes several second transactions involving the m-th third account in the second block and the block number of the second block to which each of them belongs.

[0031] Service nodes, including blockchain nodes, can manage the block data they generate / query in chronological order. See also Figure 3 As shown, for consecutive time intervals Epoch-1 and Epoch-2, the blockchain system may generate multiple blocks within a single time interval. For example, Epoch-1 may generate 6 blocks with block numbers from V1 to V6, and Epoch-2 may generate 6 blocks with block numbers from V7 to V12. A corresponding storage file can be created for these consecutive blocks to store on-chain data of multiple accounts involved in multiple transactions within those blocks. For example, storage file File-1 can be created for blocks V1 and V2, File-2 for blocks V3 and V4, File-3 for blocks V5 and V6, File-4 for blocks V7 and V8, File-5 for blocks V9 and V10, and File-6 for blocks V11 and V12.

[0032] Taking the second block as block V3 of the aforementioned example, and block V3 including transactions Tx31 and Tx32 from the aforementioned example, as an example, please continue reading. Figure 3As shown, step S23 described above completes the storage of the on-chain data (E-list) of Node1, Node2, and Node3, with Node1, Node2, and Node3 as keys, in the storage file File-2 corresponding to block V3. Specifically, Node1's E-list includes: transaction Tx31 and its block number V3, and transaction Tx32 and its block number V3; Node2's E-list includes: transaction Tx31 and its block number V3; and Node3's E-list includes: transaction Tx32 and its block number V3.

[0033] Building upon the block V3 and storage file File-2 in the previous example, let's assume that block V4 includes transactions Tx41 and Tx42 initiated by account Node4. Transaction Tx41 is used to transfer digital resources to account Node1, and transaction Tx42 is used to transfer digital resources to account Node2. Then, after obtaining block V4, the service nodes, including the blockchain nodes, can update the storage file File-2 corresponding to block V4 through the aforementioned step S23: adding transaction Tx41 and its block number V4 to the E-list with Node1 as the key; adding transaction Tx42 and its block number V4 to the E-list with Node2 as the key; and adding an E-list for Node4 with Node4 as the key. Node4's E-list includes: transaction Tx41 and its block number V4, and transaction Tx42 and its block number V4.

[0034] Through the aforementioned steps S21 and S23, data requesters can use accounts as keys to more quickly query transactions involving relevant accounts within the storage files corresponding to the blocks that the data requester wishes to query.

[0035] To further improve query efficiency and avoid querying a storage file with that account as the key even when the storage file does not contain the on-chain data of that account, the service node can continue to execute the following step S25 based on the aforementioned steps S21 and S23: configure the filtering component corresponding to the second block according to the m-th third account.

[0036] Service nodes can maintain different filtering components for different block sets. For example, please see [link to example]. Figure 3In the service node, filtering components RAMBO-1 and RAMBO-2 can be maintained for Epoch-1 and Epoch-2 respectively. That is, RAMBO-1 corresponds to blocks V1 to V6 generated in Epoch-1, and RAMBO-2 corresponds to blocks V7 to V12 generated in Epoch-2. In other words, RAMBO-1 corresponds to storage files File-1, File-2, and File-3, and RAMBO-2 corresponds to storage files File-4, File-5, and File-6.

[0037] The filtering component can be a filter that supports existence queries based on accounts, such as a Bloom filter. Alternatively, to improve the accuracy of existence queries, the filtering component can include multiple filter groups, which can contain multiple filters.

[0038] In the case where a single filtering component includes multiple filter groups, and a single filter group includes multiple filters, for any p-th filter group in the filtering component corresponding to the second block, the corresponding target filter can first be determined from the p-th filter group based on the storage file corresponding to the second block, and then the target filter can be configured based on the m-th third account.

[0039] Taking block V3 as the second block and Node1 as the third account as an example, this document describes the process of configuring the filtering component RAMBO-1 corresponding to block V3 based on Node1. (See also...) Figure 4As shown, RAMBO-1, which corresponds to File-1, File-2, and File-3, includes, for example, two filter groups, Table-1 and Table-2. Table-1 includes, for example, three filters BF-11, BF-12, and BF-13 arranged in sequence, and Table-2 includes, for example, three filters BF-21, BF-22, and BF-23 arranged in sequence. Block V3 corresponds to storage file File-2. For example, the hash value H1 of the identifier of storage file File-2 (e.g., file name) and the identifier of Table-1 (e.g., the sequence number 1 of Table-1 in the two filtering components included in RAMBO-1) can be calculated. Then, based on the hash value H1, the corresponding target filter (let's say the second filter BF-12) can be determined from Table-1. Next, Node1 can be used as an element that allows existence queries to calculate its hash value H2. Then, based on the hash value H2 of Node1, the target position corresponding to Node1 (e.g., the fourth position from the left in the bit sequence) can be determined from the element existence bitmap of BF-12 (which is usually represented as a bit sequence or binary vector consisting of single bit values ​​0 or 1) and the value of the target position is set to 1, completing the configuration of BF-12 based on File-2 and Node1. Based on a similar process, for example, the corresponding target filter BF-22 may also be determined from Table-2, and then BF-22 may be configured based on Node1, which will not be elaborated further.

[0040] Using the method provided in the foregoing embodiments, the service node can obtain multiple filtering components and their corresponding multiple storage files. The filtering components are used to support querying whether the on-chain data of the account to be queried exists in the corresponding storage file. Any i-th storage file includes on-chain data of multiple first accounts with multiple first accounts as keys. Any j-th first account is an account involved in the transaction in several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions involving the j-th first account in several first blocks and the block number of their respective blocks.

[0041] Figure 5This is a second flowchart of a data processing method in a blockchain system provided in the embodiments of this specification. This method can be executed by a service node, including a blockchain node. The method exemplarily describes the process of querying on-chain data of a fourth account on demand within a service node. The service node includes multiple filtering components and corresponding multiple storage files. The filtering components support querying whether on-chain data of the desired account exists in the corresponding storage files. Any i-th storage file includes on-chain data of multiple first accounts using multiple first accounts as keys. Any j-th first account is an account involved in transactions within several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions involving the j-th first account in several first blocks and the block numbers of their respective blocks.

[0042] See Figure 5 As shown, the method may include, but is not limited to, some or all of the following steps S51 to S55.

[0043] Step S51: Receive a third data query request, which indicates the fourth account to be queried and several third blocks. The following description uses the example of a data requester wanting to query the on-chain data of account Node1 within blocks V3 to V6 as an example, specifically assuming the fourth account is account Node1 and the several third blocks include blocks V3 to V6.

[0044] Step S53: Determine the fourth storage files and fourth filtering components corresponding to the third blocks.

[0045] See Figure 3 As shown, the fourth storage files corresponding to blocks V3 to V6 include, for example, storage files File-2 and File-3, and the fourth filtering components corresponding to blocks V3 to V6 include, for example, RAMBO-1.

[0046] Step S55: For any q-th fourth storage file among several fourth storage files, query whether the q-th fourth storage file contains on-chain data of the fourth account through the fourth filtering component.

[0047] In the case of a single filter, the fourth filtering component can calculate the hash value H3 of account Node1, and then determine the corresponding target position from the element existence bitmap of the filter based on the hash value H3. If the value of the target position is 1, it can be directly determined that the on-chain data E-list of Node1 is included in both storage files File-2 and File-3.

[0048] The fourth filtering component includes multiple filter groups. When a single filter group contains multiple filters, for a single fourth storage file, such as File-2, following the process of configuring the filtering component RAMBO-1 described earlier, for any p-th filter group in the filtering component, the hash value H4 of the identifier of storage file File-2 and the identifier of the p-th filter group can be calculated. The corresponding target filter is then determined from the p-th filter group. Next, the hash value H5 of Node1 is calculated, and based on the hash value H5, the corresponding target position is determined from the element existence bitmap of the target filter. Then, it is checked whether the value at that target position is 1. If it is not 1, it is directly determined that storage file File-2 does not contain on-chain data of Node1. Conversely, if the target position in the existence bitmap of the target filter is found to be 1 through multiple target filters in the multiple filter groups included in the fourth filtering component, it indicates that storage file File-2 contains the on-chain data E-list of Node1.

[0049] If the q-th fourth storage file contains on-chain data of the fourth account, then proceed to step S57 to query the on-chain data of the fourth account from the q-th fourth storage file.

[0050] When there are multiple fourth storage files determined in step S53, step S55 may determine that the number of fourth storage files containing the on-chain data of the fourth account is not less than 1. This may lead to step S57 where the on-chain data of the fourth account is queried from multiple fourth storage files containing the on-chain data of the fourth account, and then all the on-chain data of the fourth account that has been queried is returned, thus completing the response to the third data query request.

[0051] Alternatively, steps S53 and S55 can be implemented in other ways. For example, for all filters in multiple filter groups in the fourth filtering component, the existence of the fourth account as the key can be queried in a traversal manner. Through the pre-recorded correspondence between filters and storage files, a set of storage files that may contain the fourth account as the key can be obtained for a single filter group. Then, the intersection of the storage file sets corresponding to the multiple filter groups can be taken, and the on-chain data with the fourth account as the key can be found from each storage file in the intersection.

[0052] The service node can also record the process of responding to multiple data query requests received within a predetermined time period before the current moment, as well as the query frequency of each storage file. This allows the filtering component to be merged based on the query frequency of the storage files, thereby saving storage resources.

[0053] For two storage files corresponding to the same filtering component, the aforementioned multiple query requests may include multiple first query requests corresponding to the two storage files. When responding to a single first query request, the service node will query the on-chain data of the same account from both storage files. Therefore, for any two storage files corresponding to the same filtering component across multiple consecutive blocks, the service node can also count the number of first query requests involving the two storage files to make subsequent decisions on whether to merge the two storage files.

[0054] For a single account in two storage files corresponding to the same filtering component, the aforementioned multiple query requests may include multiple second query requests corresponding to that account. When responding to a single second query request, the service node will query the on-chain data of that account from both storage files. If the number of second query requests is relatively large, indicating that the account is a frequently accessed "hot" account, it suggests that the data requester may subsequently initiate query requests to retrieve the on-chain data of that account from the two storage files. Therefore, for any two single accounts in storage files corresponding to the same filtering component across multiple consecutive blocks, the service node can also count the number of second query requests related to that account to inform subsequent decisions on whether to merge the two storage files.

[0055] Figure 6 This is the third flowchart of a data processing method in a blockchain system provided in the embodiments of this specification. The method can be executed by a service node, including a blockchain node. The service node includes multiple filtering components and corresponding multiple storage files. The filtering components support querying whether the on-chain data of the desired account exists in the corresponding storage file. Any i-th storage file includes on-chain data of multiple first accounts with multiple first accounts as keys. Any j-th first account is an account involved in transactions within several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions involving the j-th first account in several first blocks and the block numbers of their respective blocks. This method exemplarily describes the process of merging two storage files. This method can reduce the frequency with which the service node queries the corresponding file for the existence of on-chain data of a certain account in subsequent responses to single query requests, and reduces the probability of querying the same account's on-chain data from multiple storage files, thereby enabling the service node to respond to data query requests more quickly.

[0056] See Figure 6 As shown, the method may include, but is not limited to, the following steps S61 and S65.

[0057] Step S61: Determine a first storage file and a second storage file from multiple storage files, wherein the first storage file and the second storage file correspond to the same target filtering component, including on-chain data with the same second account as the key.

[0058] The first and second storage files correspond to multiple consecutive blocks. For example, the first and second storage files could be storage files File-2 and File-3, which correspond to consecutive blocks V3 to V6.

[0059] The first and second storage files can be determined based on multiple first data query requests responded to within a preset time period prior to the current moment. The number of these multiple first query requests is not less than a first preset number. The process of a service node responding to a single first data query request includes querying the on-chain data of the same account from both the first and second storage files. It can be understood that the larger the number of first query requests corresponding to the first and second storage files, the greater the likelihood that the service node will need to query the on-chain data of the same account from both the first and second storage files when responding to subsequent single query requests.

[0060] The first and second storage files can be determined based on multiple second data query requests responded to within a preset time period prior to the current moment. The number of these multiple second query requests is not less than a second preset number. The process of a service node responding to a single second data query request includes querying the on-chain data of the second account from both the first and second storage files. It can be understood that for a second account involved in both the first and second storage files, the larger the number of second query requests corresponding to that second account, the greater the likelihood that the service node will need to query the on-chain data of the second account from both the first and second storage files when responding to subsequent single query requests.

[0061] For example, consider two storage files, File-2 and File-3, which correspond to multiple consecutive blocks and involve the same accounts, Node1 and Node2. If, within a preset time period T prior to the current moment, the number of first query requests for File-2 and File-3 that the service node has responded to reaches a first preset number, or the number of second query requests for the same accounts Node1 / Node2 involved in File-2 and File-3 that the service node has responded to reaches a second preset number, then storage files File-2 and File-3 can be identified as the first and second storage files to be merged.

[0062] Step S63: Merge the first storage file and the second storage file into a third storage file.

[0063] For on-chain data in the first and second storage files that use different accounts as keys, they can be stored separately in the merged third storage file. See also Figure 7 As shown, the storage files to be merged are File-2 and File-3. File-2 contains on-chain data E-list with Node1, Node2, Node3, and Node4 as keys, and File-3 contains on-chain data E-list with Node1, Node2, and Node5 as keys. Therefore, the on-chain data E-list with Node3 and Node4 as keys in File-2, and the on-chain data E-list with Node5 as key in File-2 can be directly stored in the merged storage file File-23.

[0064] For on-chain data with the same account as the key in the first and second storage files, the on-chain data with the same account can be merged, and the merged on-chain data with the same account as the key can be stored in the merged third storage file. See also Figure 7 As shown, both File-2 and File-3 contain E-lists with Node1 and Node2 as keys. Therefore, the E-lists with Node1 as the key in File-2 and File-3 can be merged, and the E-lists with Node2 as the key in File-2 and File-3 can be merged. Then, the merged E-lists with Node1 as the key and the merged E-lists with Node2 as the key can be stored in the merged storage file File-23 respectively. For example, the E-list of Node 1 in File-2 includes: transaction Tx31 and its block number V3, transaction Tx32 and its block number V3, and transaction Tx41 and its block number V4; the E-list of Node 1 in File-3 includes: transaction Tx51 and its block number V5, and transaction Tx61 and its block number V6; the E-list of Node 1 in the merged File-23 includes: transaction Tx31 and its block number V3, transaction Tx32 and its block number V3, transaction Tx41 and its block number V4, transaction Tx51 and its block number V5, and transaction Tx61 and its block number V6.

[0065] If a third storage file is obtained by merging, the first and second storage files can be deleted.

[0066] Step S65: The target filtering component corresponding to the first and second storage files is reconfigured to the filtering component corresponding to the third storage file.

[0067] If the filtering component is a single filter, the target filtering component that originally corresponded to the first and second storage files can be directly identified as the filtering component that corresponds to the third storage file.

[0068] When the filtering component includes multiple filter groups, the target filtering component can be initialized. That is, for the element existence bitmap of all filters in the target filtering component, the values ​​of all positions in the element existence bitmap can be set to 0. Furthermore, referring to the process of configuring RAMBO-1 based on storage file File-2 and Node1 described above, for any p-th filter group in the target filtering component, the corresponding target filter can be determined from the p-th filter group according to the third storage file, and then the target filter can be configured according to the account used as the key in the third storage file. It should be noted that if the storage file corresponding to the target filtering component also includes other storage files besides the first and second storage files, the initialized target filtering component also needs to be configured according to the other storage files.

[0069] Figure 8 This is the fourth flowchart of a data processing method in a blockchain system provided in the embodiments of this specification. The method can be executed by a service node, including blockchain nodes. The service node includes multiple filtering components and their corresponding multiple storage files. The filtering components support querying whether on-chain data of the desired account exists in the corresponding storage file. Any i-th storage file includes on-chain data of multiple first accounts with multiple first accounts as keys. Any j-th first account is an account involved in transactions within several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions involving the j-th first account in several first blocks and the block numbers of their respective blocks. This method exemplarily describes the process of merging two filtering components. This method can reduce the storage overhead of the multiple filtering components stored by the service node without significantly negatively impacting the subsequent response to query requests, thereby saving the service node's storage resources.

[0070] See Figure 8 As shown, the method may include, but is not limited to, the following steps S81 and S83.

[0071] Step S81: Determine the first filter component and the second filter component to be merged from multiple filter components.

[0072] The first and second filtering components correspond to multiple consecutive blocks. For example, the first and second filtering components can be RAMBO-1 and RAMBO-2 corresponding to consecutive blocks V1 to V12.

[0073] In one possible implementation, the storage files corresponding to the first and second filtering components are queried less frequently than a third preset number within a preset time period prior to the current moment. It can be understood that if the storage files corresponding to the first and second filtering components are queried less frequently than the third preset number within the preset time period prior to the current moment, it indicates that the service node is less likely to need to use the first and second filtering components to query whether on-chain data for a certain account exists in the corresponding storage files during its subsequent response to a single received query request.

[0074] In one possible implementation, the minimum height difference between the latest block obtained by the service node and several blocks corresponding to the first and second filtering components reaches a preset threshold. For example, if the highest block corresponding to the second filtering component is block V12, when the height difference between the latest block Vn and block V12 reaches a relatively large preset threshold, the service node is less likely to use RAMBO-1 and RAMBO-2 to query whether on-chain data of a certain account exists in the corresponding storage file during its subsequent response to a single received query request.

[0075] Step S83: The first filter component and the second filter component are merged into a third filter component, wherein the storage file corresponding to the third filter component includes the storage files corresponding to the first filter component and the second filter component respectively.

[0076] Taking RAMBO-1 as the first filter component and RAMBO-2 as the second filter component as an example, the process of merging RAMBO-1 and RAMBO-2 to obtain the third filter component RAMBO-12 is described exemplarily.

[0077] When RAMBO-1, RAMBO-2, and RAMBO-12 are single filters, for the nth position in the element presence bitmap of RAMBO-12, if the value of the nth position in the element presence bitmap of RAMBO-1 and / or RAMBO-2 is 1, then the value of that position is set to 1; if the value of the nth position in the element presence bitmap of RAMBO-1 and RAMBO-2 is 0, then the value of that position is set to 0.

[0078] When RAMBO-1, RAMBO-2, and RAMBO-12 consist of multiple filter groups, the g-th filter of the p-th filter group in RAMBO-12 is obtained by merging the g-th filters of the p-th filter groups in RAMBO-1 and RAMBO-2. The method of merging filters can be found in the previous text and will not be repeated here.

[0079] When a third filter component is obtained by merging, the first and second filter components can be deleted. For example, after merging RAMBO-1 and RAMBO-2 to obtain RAMBO-12, RAMBO-1 and RAMBO-2 can be deleted. The merged RAMBO-12 corresponds to the storage files File-1 to File-6 and to blocks V1 to V12.

[0080] In some embodiments, the service node may also store multiple versions of state data corresponding to multiple filtering components, for example, storing multiple versions of state data corresponding to multiple filtering components in a snapshot manner; for corresponding filtering components and state data, the version of the state data may be, for example, the block height of any block corresponding to the filtering component. See also Figure 3 For example, the service node can store the state data corresponding to RAMBO-1 and RAMBO-2 respectively. The state data corresponding to RAMBO-1 is, for example, the state data corresponding to any block among blocks V1 to V6, and the state data corresponding to RAMBO-1 is, for example, the state data corresponding to any block among blocks V7 to V12.

[0081] When the first and second filter components are merged into a third filter component, the state data corresponding to one of the first or second filter components can be used as the state data corresponding to the third filter component, and the state data corresponding to the other filter component can be deleted.

[0082] Based on the same concept as the aforementioned method embodiments, this specification also provides a data processing device 900 in a blockchain system. The device 900 is deployed in a service node, which includes multiple filtering components and corresponding multiple storage files. The filtering components are used to support querying whether on-chain data of the desired account exists in the corresponding storage files. Any i-th storage file includes on-chain data of the multiple first accounts with multiple first accounts as keys. Any j-th first account is an account involved in transactions within several first blocks corresponding to the i-th storage file. The on-chain data of the j-th first account includes several first transactions involving the j-th first account in the several first blocks and the block numbers of their respective blocks. Figure 9As shown, the device 900 includes: a merging determination unit 91, configured to determine a first storage file and a second storage file from the plurality of storage files, wherein the first storage file and the second storage file correspond to the same target filtering component, including on-chain data with the same second account as the key; a merging processing unit 92, configured to merge the first storage file and the second storage file into a third storage file; and a configuration processing unit 93, configured to configure the target filtering component as a filtering component corresponding to the third storage file.

[0083] In one possible implementation, the filtering component includes multiple filter groups, and each filter group includes multiple filters; wherein, the configuration processing unit 93 is configured to initialize the target filtering component; for any p-th filter group in the target filtering component, determine the corresponding target filter from the p-th filter group according to the third storage file; and configure the target filter according to the account used as the key in the third storage file.

[0084] In one possible implementation, the first storage file and the second storage file are determined based on a plurality of first data query requests that have been responded to within a preset time period prior to the current time, wherein the number of the plurality of first query requests is not less than a first preset number, and the process of responding to a single first data query request includes querying on-chain data of the same account from the first storage file and the second storage file respectively.

[0085] In one possible implementation, the first storage file and the second storage file are determined based on a plurality of second data query requests that have been responded to within a preset time period prior to the current time, wherein the number of the plurality of second query requests is not less than a second preset number, and the process of responding to a single second data query request includes querying the on-chain data of the second account from the first storage file and the second storage file.

[0086] In one possible implementation, the merging determination unit 91 is further configured to determine a first filter component and a second filter component from the plurality of filter components; the merging processing unit 92 is further configured to merge the first filter component and the second filter component into a third filter component, wherein the storage file corresponding to the third filter component includes the storage files corresponding to the first filter component and the second filter component respectively.

[0087] In one possible implementation, the storage files corresponding to the first filtering component and the second filtering component are queried less frequently than a third preset number within a preset time period prior to the current moment.

[0088] In one possible implementation, the minimum height difference between the latest block obtained by the service node and several blocks corresponding to the first filtering component and the second filtering component reaches a preset threshold.

[0089] In one possible implementation, the service node is a blockchain node, and the device further includes: an account determination unit 94 configured to determine multiple third accounts involved in transactions in the latest generated second block of the blockchain system; a storage processing unit 95 configured to, for any m-th third account, store the on-chain data of the m-th third account in a storage file corresponding to the second block, using the m-th third account as the key, wherein the on-chain data of the m-th third account includes several second transactions involving the m-th third account in the second block and the block number of the second block to which each of them belongs; and a configuration processing unit 93 further configured to configure a filtering component corresponding to the second block based on the m-th third account.

[0090] In one possible implementation, the filtering component includes multiple filter groups, and each filter group includes multiple filters; wherein, the configuration processing unit 93 is specifically configured to, for any p-th filter group in the filtering component corresponding to the second block, determine the corresponding target filter from the p-th filter group according to the storage file corresponding to the second block; and configure the target filter according to the m-th third account.

[0091] In one possible implementation, the apparatus further includes: a query processing unit 96 configured to receive a third data query request, the third data query request indicating a fourth account to be queried and a plurality of third blocks; determine a plurality of fourth storage files and a fourth filtering component corresponding to the plurality of third blocks; for any q-th fourth storage file among the plurality of fourth storage files, query through the fourth filtering component whether the q-th fourth storage file includes on-chain data of the fourth account; if so, query the on-chain data of the fourth account from the q-th fourth storage file.

[0092] This specification also provides a computer-readable storage medium storing a computer program, which, when executed in a computer, causes the computer to perform the method steps executed by the service node in any of the foregoing method embodiments.

[0093] This specification also provides a computing device in its embodiments, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements the method steps executed by the service node in any of the foregoing method embodiments.

[0094] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0095] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0096] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0097] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0098] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0099] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0100] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0101] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0102] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0103] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0104] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0105] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0107] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0108] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A data processing method in a blockchain system, the method being executed by a service node, the service node comprising multiple filtering components and corresponding multiple storage files, the filtering components being used to support querying whether on-chain data of a desired account exists in the corresponding storage files, any i-th storage file comprising on-chain data of the multiple first accounts with multiple first accounts as keys, any j-th first account being an account involved in transactions in a plurality of first blocks corresponding to the i-th storage file; the on-chain data of the j-th first account comprising a plurality of first transactions involving the j-th first account in the plurality of first blocks and the block number of each of the blocks to which they belong; the method comprising: A first storage file and a second storage file are determined from the plurality of storage files, wherein the first storage file and the second storage file correspond to a plurality of consecutive blocks and the same target filtering component, including on-chain data with the same second account as the key; The first and second storage files are merged into a third storage file, and the target filtering component is reconfigured to correspond to the third storage file.

2. The method according to claim 1, wherein the filtering assembly comprises a plurality of filter groups, and a single filter group comprises a plurality of filters; wherein, The step of reconfiguring the target filtering component to correspond to the filtering component of the third storage file includes: Initialize the target filtering component; For any p-th filter group in the target filtering component, the corresponding target filter is determined from the p-th filter group according to the third storage file; The target filter is configured based on the account used as the key in the third storage file.

3. The method according to claim 2, wherein the first storage file and the second storage file are determined based on a plurality of first data query requests that have been responded to within a preset time period prior to the current time, wherein the number of the plurality of first data query requests is not less than a first preset number, and the process of responding to a single first data query request includes querying on-chain data of the same account from the first storage file and the second storage file respectively; And / or, The first storage file and the second storage file are determined based on a plurality of second data query requests that have been responded to within a preset time period prior to the current time. The number of the plurality of second data query requests is not less than a second preset number. The process of responding to a single second data query request includes querying the on-chain data of the second account from the first storage file and the second storage file.

4. The method according to claim 1, further comprising: A first filter component and a second filter component are determined from the plurality of filter components; The first filtering component and the second filtering component are merged into a third filtering component, wherein the storage file corresponding to the third filtering component includes the storage file corresponding to each of the first filtering component and the second filtering component.

5. The method according to claim 4, wherein the frequency of queries on the storage files corresponding to the first filtering component and the second filtering component within a preset time period prior to the current time is less than a third preset number; and / or, The minimum height difference between the latest block obtained by the service node and several blocks corresponding to the first filtering component and the second filtering component reaches a preset threshold.

6. The method according to claim 1, wherein the method is executed by a blockchain node, and the method further comprises: Identify multiple third accounts involved in the transactions within the most recently generated second block of the blockchain system; For any m-th third account, in the storage file corresponding to the second block, the on-chain data of the m-th third account is stored with the m-th third account as the key. The on-chain data of the m-th third account includes several second transactions involving the m-th third account in the second block and the block number of the second block to which each of them belongs. Configure the filtering component corresponding to the second block according to the m-th third account.

7. The method of claim 6, wherein the filtering assembly comprises a plurality of filter groups, and a single filter group comprises a plurality of filters; wherein, The step of configuring the filtering component corresponding to the second block according to the m-th third account includes: For any p-th filter group in the filtering components corresponding to the second block, the corresponding target filter is determined from the p-th filter group according to the storage file corresponding to the second block; Configure the target filter according to the m-th third account.

8. The method according to any one of claims 1-7, further comprising: Receive a third data query request, the third data query request indicating a fourth account and several third blocks to be queried; Determine a plurality of fourth storage files and a fourth filtering component corresponding to the plurality of third blocks; For any q-th fourth storage file among the plurality of fourth storage files, the fourth filtering component queries whether the q-th fourth storage file includes the on-chain data of the fourth account; If so, query the on-chain data of the fourth account from the qth fourth storage file.

9. A data processing apparatus in a blockchain system, the apparatus being deployed in a service node, the service node including multiple filtering components and multiple corresponding storage files, the filtering components being used to support querying whether on-chain data of a desired account exists in the corresponding storage files, any i-th storage file including on-chain data of the multiple first accounts with multiple first accounts as keys, any j-th first account being an account involved in transactions in a plurality of first blocks corresponding to the i-th storage file; the on-chain data of the j-th first account including a plurality of first transactions involving the j-th first account in the plurality of first blocks and the block number of each of the blocks to which they belong; the apparatus comprising: The merging and determining unit is configured to determine a first storage file and a second storage file from the plurality of storage files, wherein the first storage file and the second storage file correspond to a plurality of consecutive blocks and the same target filtering component, including on-chain data with the same second account as the key; The merging processing unit is configured to merge the first storage file and the second storage file into a third storage file; The configuration processing unit is configured to configure the target filtering component as a filtering component corresponding to the third storage file.

10. The apparatus of claim 9, wherein the filtering assembly comprises a plurality of filter groups, and a single filter group comprises a plurality of filters; wherein, The configuration processing unit is configured to initialize the target filtering component; for any p-th filter group in the target filtering component, determine the corresponding target filter from the p-th filter group according to the third storage file; and configure the target filter according to the account used as the key in the third storage file.

11. The apparatus according to claim 9, wherein, The merging determination unit is further configured to determine a first filter component and a second filter component from the plurality of filter components; the merging processing unit is further configured to merge the first filter component and the second filter component into a third filter component, wherein the storage file corresponding to the third filter component includes the storage files corresponding to the first filter component and the second filter component respectively.

12. The apparatus according to claim 9, wherein the service node is a blockchain node, and the apparatus further comprises: An account determination unit is configured to determine multiple third accounts involved in transactions in the latest generated second block of the blockchain system; The storage processing unit is configured to, for any m-th third account, store the on-chain data of the m-th third account in the storage file corresponding to the second block, using the m-th third account as the key. The on-chain data of the m-th third account includes several second transactions involving the m-th third account in the second block and the block number of the second block to which each of them belongs. The configuration processing unit is further configured to configure a filtering component corresponding to the second block based on the m-th third account.

13. The apparatus of claim 12, wherein the filtering assembly comprises a plurality of filter groups, and a single filter group comprises a plurality of filters; wherein, The configuration processing unit is specifically configured to, for any p-th filter group in the filtering components corresponding to the second block, determine the corresponding target filter from the p-th filter group according to the storage file corresponding to the second block; and configure the target filter according to the m-th third account.

14. The apparatus according to any one of claims 9-13, further comprising: The query processing unit is configured to receive a third data query request, wherein the third data query request indicates a fourth account and several third blocks to be queried; Determine a plurality of fourth storage files and a fourth filtering component corresponding to the plurality of third blocks; for any q-th fourth storage file among the plurality of fourth storage files, query whether the q-th fourth storage file includes the on-chain data of the fourth account through the fourth filtering component; if so, query the on-chain data of the fourth account from the q-th fourth storage file.

15. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-8.

16. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-8.

Images