Blockchain data processing method and apparatus, and computer device

Abstract

This application applies to the fields of blockchain and data processing technology, providing a method, apparatus, and computer device for processing blockchain data. The method includes: when reading data stored in the blockchain based on an account address, obtaining the state index storage information corresponding to the data, wherein the state index storage information is constructed in the form of KV key-value pairs and used to store the physical K value corresponding to each node in the state tree; determining the path depth of the leaf node where the account address is located, wherein the path depth represents the number of target nodes contained in the storage path of the data; determining the current path field of each target node; determining the physical K value corresponding to each target node in the state tree based on the current path field; reading the physical V value corresponding to the physical K value of each target node in parallel to obtain the complete storage path, and reading the data through the storage path. Using the above method can improve the read and write efficiency of blockchain data.

Description

Technical Field

[0001] This application belongs to the field of blockchain and data processing technology, and in particular relates to a method, apparatus and computer equipment for processing blockchain data. Background Technology

[0002] Ledger bloat is one of the main problems affecting blockchain performance. As the amount of ledger data continues to increase, the ever-expanding ledger will affect the speed at which the blockchain can read and write data.

[0003] Specifically, at the data writing level, each blockchain node needs to store multiple types of data, such as block data, index data, state data, snapshot data, and log data. Using a single disk to store these various data types in related technologies can easily lead to problems such as excessive single-disk write load and reduced write speed due to the large volume of data.

[0004] At the data reading level, one of the main factors affecting the performance of blockchain nodes is the speed of reading blockchain state data. In related technologies, the state tree is the primary structure for storing blockchain state data. Reading a target value from the state tree involves reading layer by layer from the root node down to the leaf nodes; this process is sequential. Since each node read corresponds to one disk input / output (IO), as the blockchain ledger data continues to grow and the average depth of the state tree gradually increases, the average number of IO operations per data read also increases, leading to a continuous increase in the total data reading time and severely impacting data reading efficiency. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, apparatus, and computer device for processing blockchain data, in order to improve the efficiency of reading and writing blockchain data.

[0006] The first aspect of this application provides a method for processing blockchain data, including:

[0007] When reading data stored in the blockchain based on an account address, the state index storage information corresponding to the data to be read is obtained. The state index storage information is constructed in the form of KV key-value pairs and is used to store the physical K value corresponding to each node in the state tree.

[0008] Determine the path depth of the leaf node where the account address is located, where the path depth represents the number of target nodes contained in the storage path of the data;

[0009] Determine the current path field of each of the target nodes;

[0010] Based on the current path field, determine the physical K value corresponding to each target node in the state tree;

[0011] The physical V value corresponding to the physical K value of each target node is read in parallel to obtain the complete storage path, and the data is read through the storage path.

[0012] In one possible implementation of this application embodiment, the state index storage information is obtained when the data is written to the blockchain, and determining the path depth of the leaf node where the account address is located includes:

[0013] Query the path depth of the leaf node containing the account address from the state index storage information.

[0014] In one possible implementation of this application embodiment, determining the current path field of each of the target nodes includes:

[0015] Based on the prefix tree addressing principle, field information for indicating the current path of each target node is determined, wherein the current path is the addressing position of the corresponding target node in the state tree.

[0016] In one possible implementation of this application embodiment, determining the physical K value corresponding to each target node in the state tree based on the current path field includes:

[0017] Historical version information of each target node is obtained in parallel from the state index storage information;

[0018] Based on the historical version information and the addressing location, the physical K value corresponding to each target node is constructed.

[0019] In one possible implementation of this application embodiment, the parallel reading of the physical V value corresponding to the physical K value of each target node to obtain the complete storage path includes:

[0020] The physical V values ​​corresponding to the physical K values ​​of each target node are read in parallel from the state storage information.

[0021] According to the order of each target node, the multiple physical V values ​​are combined into the complete data storage path.

[0022] In one possible implementation of this application embodiment, before obtaining the state index storage information corresponding to the data to be read, the method further includes:

[0023] The data type is determined, and each data type is configured with a corresponding disk storage path, where the disk storage path represents a disk area on the disk where the corresponding data type is stored.

[0024] According to the disk storage path, the data is stored in the corresponding disk area to achieve partitioned storage of blockchain data.

[0025] In one possible implementation of this application embodiment, each type of data has a corresponding access frequency, and the disk storage path corresponding to different types of data indicates disk areas on different disks; wherein, the performance of different disks is positively correlated with the access frequency of the stored data.

[0026] A second aspect of this application provides a blockchain data processing apparatus, comprising:

[0027] The state index storage information acquisition module is used to acquire the state index storage information corresponding to the data to be read when reading data stored in the blockchain according to the account address. The state index storage information is constructed in the form of KV key-value pairs and is used to store the physical K value corresponding to each node in the state tree.

[0028] The path depth determination module is used to determine the path depth of the leaf node where the account address is located, wherein the path depth represents the number of target nodes contained in the storage path of the data;

[0029] The current path field determination module is used to determine the current path field of each of the target nodes respectively;

[0030] The physical K-value determination module is used to determine the physical K-value corresponding to each target node in the state tree based on the current path field.

[0031] The storage path determination module is used to read the physical V value corresponding to the physical K value of each target node in parallel to obtain the complete storage path.

[0032] A data reading module is used to read the data through the storage path.

[0033] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the computer device performs the method as described in any of the first aspects above.

[0034] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a computer, implements the method described in any of the first aspects above.

[0035] A fifth aspect of this application provides a computer program product, including a computer program that, when the computer program is run, causes the method described in any of the first aspects above to be executed.

[0036] Compared with the prior art, the embodiments of this application have the following beneficial effects:

[0037] This application embodiment can construct a state index storage information in the form of KV key-value pairs when data is written to the blockchain or generated during blockchain operation. This index stores the physical K values ​​corresponding to each node in the state tree. Therefore, when reading relevant data stored in the blockchain based on an account address, efficient data reading and writing can be achieved by obtaining the state index storage information corresponding to that data. Specifically, this application embodiment can determine the number of target nodes contained in the storage path of the data to be read by determining the path depth of the leaf node where the account address is located. After determining the current path field of each target node, the physical K value corresponding to each target node in the state tree can be determined based on the current path field. Then, the physical V values ​​corresponding to the physical K values ​​of each target node can be read in parallel to obtain the complete storage path of the data to be read, i.e., the Merkel path. By introducing a state tree indexing mechanism, this application embodiment can construct the keys of all tree nodes on the Merkel path at once based on the target key information and the state tree index when reading the Merkel path. In this way, when a request to read the Merkel path in parallel is initiated on the disk, the construction time of the Merkel path can be reduced on disks that support parallel reading (such as solid-state drives SSDs), thereby speeding up the efficiency and speed of reading data based on the Merkel path. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying 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.

[0039] Figure 1 This is a schematic diagram of a blockchain data processing method provided in an embodiment of this application;

[0040] Figure 2 This is a schematic diagram of a state tree provided in an embodiment of this application;

[0041] Figure 3 This is a schematic diagram illustrating a process of constructing a storage path for data from state index storage information, as provided in an embodiment of this application.

[0042] Figure 4 This is a schematic diagram of a blockchain data processing device provided in an embodiment of this application;

[0043] Figure 5 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0044] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0045] Blockchain systems generate various types of data during operation, such as block data, state data, index data, snapshot data, and log data. Furthermore, data nodes in the blockchain (nodes holding all historical data) also need to store archived data. The importance and accessibility of this data vary. If this data is not finely partitioned, and instead a single disk, or even the same storage engine, is used to store different types of data, it can easily lead to excessive read / write loads on a single disk. This is especially true in blockchain systems that need to handle high transaction per second (TPS), where a single disk will significantly reduce data read / write speeds. Moreover, due to the limited capacity of a single disk, using a single disk to store various types of data makes vertical scaling of storage space difficult.

[0046] Furthermore, most common blockchain systems currently use state trees as the data structure for storing the historical states of accounts and contracts. Representative state trees include the MPT (Merkle Patricia Tree) used by Ethereum and the JMT (Jellyfish Merkle Tree) used by Aptos. The conventional way to read a blockchain state tree is to read it layer by layer from the root node down until the target leaf node is obtained at the bottom. Since each node in the blockchain state tree corresponds to a key-value (KV) data pair in the blockchain ledger, reading a node in the state tree actually corresponds to one disk I / O operation. As the blockchain ledger data continues to grow, the average depth of the state tree gradually increases, and the average number of I / O operations per data entry also increases, leading to a continuous increase in the total data reading time and severely impacting data read / write efficiency.

[0047] To address the aforementioned issues, this application provides a blockchain data processing method. This method can partition and store data from various blockchain nodes across multiple disks based on the size of different data types and / or the degree of data accessibility. This achieves the goals of supporting parallel writing, vertical scaling, and reducing hardware costs. Furthermore, this application introduces a state tree indexing mechanism. When reading the storage path of data, based on the target key (physical K value) and the state tree index, the keys of all state tree nodes on the storage path can be constructed at once. This reduces the path construction time when initiating parallel read requests on the disk, thereby improving the overall read and write efficiency of blockchain data.

[0048] The technical solution of this application will be described below through specific embodiments.

[0049] Reference Figure 1 The diagram illustrates a blockchain data processing method provided in an embodiment of this application, which may specifically include the following steps:

[0050] S101. When reading data stored in the blockchain according to the account address, obtain the state index storage information corresponding to the data to be read. The state index storage information is constructed in the form of KV key-value pairs and is used to store the physical K value corresponding to each node in the state tree.

[0051] It should be noted that this method can be applied to blockchain. The executing entity of this method can be a computer device connected to the blockchain system. That is, by executing the various steps of this method, the computer device can achieve efficient data reading and writing. The aforementioned computer device can be a desktop computer connected to the blockchain system, such as a desktop computer or an all-in-one computer, or it can be a cloud server or other devices. This application embodiment does not limit the specific type of computer device.

[0052] In this embodiment of the application, the data to be read can be blockchain data, that is, data stored in the blockchain.

[0053] To facilitate a better understanding of the embodiments of this application, the data storage process, that is, the process of writing data into the blockchain, will be introduced first.

[0054] In this embodiment, the computer device can write data to the blockchain using a partitioning or disk-based management strategy based on different data types. Disk-based data management refers to using multiple disks to store data, with each type of data stored on a different disk after being written to the blockchain. Therefore, for different types of data, the computer device can pre-configure a corresponding disk storage path for each type of data. This disk storage path can represent a disk area on the disk where the corresponding type of data is stored. For example, the configured disk storage path for a certain type of data (data A) can be a storage path on disk A, indicating that data A will be stored on disk A after being written to the blockchain; similarly, the configured disk storage path for another type of data (data B) can be a storage path on disk B, indicating that data B will be stored on disk B after being written to the blockchain.

[0055] Therefore, when a computer device writes data to the blockchain, the computer device can first determine the type of data to be written. Since the disk storage paths corresponding to different types of data can indicate different disk areas on different disks, the data can be stored in the corresponding disk area according to the disk storage path corresponding to the type of data, thereby realizing the partitioned storage of blockchain data.

[0056] In one possible implementation of this application, based on the needs of the blockchain system during operation and the data generated, the blockchain data can be pre-divided into multiple types, and these different types of data can be partitioned and stored accordingly.

[0057] In the embodiments of this application, each type of data may have a corresponding access frequency, which can represent the frequency with which the data is read and written.

[0058] Table 1 shows an example of blockchain data type classification provided in this application embodiment, and a comparison of the content, data volume, and access frequency of each type of data.

[0059] Table 1. Blockchain Data Classification

[0060]

[0061] As shown in Table 1, blockchain data is divided into block data, state data, index data, snapshot data, other data, and archived data. Archived data is unique to each data node in the blockchain. The data volume and access frequency of these six types of data are not entirely the same. Specifically, in terms of data volume, archived data is the largest, while logs, consensus messages, and other data have the smallest volume. In addition, block data also has a relatively large volume, state data is generally smaller than block data, and index data and snapshot data are relatively smaller. Regarding access frequency, state data is accessed most frequently, snapshot data is also accessed relatively frequently, block data and index data have moderate access frequencies, archived data has a lower access frequency, and logs, consensus messages, and other data have an even lower access frequency.

[0062] Of course, the classification shown in Table 1 is only one example provided by the embodiments of this application. In different scenarios, other classification methods can be adopted according to actual needs. The embodiments of this application do not limit this.

[0063] Taking the classification shown in Table 1 as an example, after classifying blockchain data based on the above method, data can be partitioned or stored on different disks according to different types of data when writing data, thus forming blockchain data partitions.

[0064] In one possible implementation of this application, the performance of different disks can be positively correlated with the access frequency of the stored data. For example, the higher the access frequency of data, the better the disk can be used to store it. Therefore, this application embodiment can use different disks to store different types of data according to their access frequency, thereby achieving differentiated configuration based on the data's access frequency.

[0065] For example, since block data, index data, archived data, and other data are accessed relatively infrequently, low-performance, high-capacity HDDs can be used for storage. However, for frequently accessed data such as status data and snapshot data, high-performance, high-capacity SSDs can be used. HDDs are mechanical hard drives that rely on rotating disk platters to store data, and data can be read and written using read / write heads. SSDs are solid-state drives that use flash memory chips as the storage medium; data can be stored directly on semiconductor chips without mechanical movement. HDDs have slower read / write speeds, limited by disk rotation speed, resulting in slow random read / write speeds, making them suitable for sequential read / write of large amounts of data. SSDs have significantly faster read / write speeds than HDDs, performing exceptionally well in random read / write operations, allowing for faster and smoother system startup, program loading, and other everyday operations.

[0066] In this embodiment, after storing the data in the aforementioned manner, the computer device can generate a state index storage information for the stored or written data. This state index storage information can be obtained when the data is written to the blockchain, and it can be constructed in the form of key-value pairs (KV) to store the physical K value corresponding to each node in the state tree. A state tree is a data structure used in a blockchain system to store the historical states of accounts and contracts, including the MPT tree used by Ethereum and the JMT tree used by Aptos.

[0067] In one possible implementation of this application embodiment, for a state tree of the JMT tree type, the state index storage information may include the following:

[0068] <Contract Address + Current Path> -><History>

[0069] <Contract Address + Full Path> -><Path Depth>

[0070] Here, "current path" refers to the address position of the current node in the blockchain's state tree. "Full path" in the account state tree can refer to the hexadecimal code of the account address, and in the contract state tree, it can refer to the hexadecimal code of the contract storage slot. "Path depth" indicates the depth of the leaf node containing the target account or target contract storage slot in the state tree. For example, the path depth of the root node is 1, the path depth of the next level node of the root node is 2, and so on. Historical version indicates the block height at which the current node was last updated. In the state index storage information, the contract address can be omitted for the account state tree.

[0071] As shown in Figure 2, this is an example of a state tree provided in an embodiment of this application. Figure 2 In the state tree shown, each node corresponds to a key-value pair stored on the physical disk. The physical key-value pair (KV) is composed of three variables: <historical version>, <contract address>, and <current path>. The historical version represents the block height at which the subtree rooted at the current node was last updated; the contract address is used only in the contract state tree and represents the hexadecimal encoding of the contract address; the current path represents the addressing position of the current node in the state tree. The account state tree can use the hexadecimal encoding of the account address as the complete path, and the contract state tree can use the hexadecimal encoding of the contract storage slot as the complete path. The physical value (V) represents the data obtained after serializing the tree node.

[0072] exist Figure 2 In the state tree shown, the state value of an account or contract is stored in the leaf nodes of the tree. For example, Figure 2Leaf node Leaf_2 stores data for account address 10bc, leaf node Leaf_5 stores data for account address af45, leaf node Leaf_6 stores data for account address a1b8, and leaf node Leaf_7 stores data for account address a15d.

[0073] After data is written to the blockchain, or after the blockchain system generates data during operation, the relevant data can be regarded as stored in a leaf node of the state tree. The computer device can generate the state index storage information of the data and store it in the form of KV key-value pairs, which is used to quickly construct the complete storage path of the data when reading the data later.

[0074] For example, with Figure 2 Taking the leaf node Leaf_6 as an example, after storing data in the account address a1b8 corresponding to the leaf node Leaf_6, the complete storage path of the data is:<Internal_1,Internal_3,Internal_4,Leaf_6> This means that when reading data from account address a1b8 corresponding to leaf node Leaf_6, the complete path is sequentially the four nodes Internal_1, Internal_3, Internal_4, and Leaf_6. For example... Figure 2 As shown, the path depth is 4, indicating that there are 4 nodes on the path. The physical K values ​​corresponding to each node are <2024,_>, <2024,a>, <2023,a1>, and <2022,a1b>. Correspondingly, the physical V values ​​corresponding to the physical K values ​​of each node are also the information of each node, namely Internal_1, Internal_3, Internal_4, and Leaf_6.

[0075] Therefore, based on the above information, the state index storage information of the data stored in account address a1b8 can be constructed as follows:

[0076] Path depth of target account a1b8: 4

[0077] The first physics term K: <2024,_>;

[0078] The second physics term K: <2024,a>;

[0079] The third physics term K: <2023,a1>;

[0080] The 4th physics term K: <2022,a1b>;

[0081] When a computer device reads data stored in the blockchain based on an account address, it can obtain the corresponding state index storage information.

[0082] S102. Determine the path depth of the leaf node where the account address is located, where the path depth represents the number of target nodes contained in the storage path of the data.

[0083] In this embodiment of the application, the path depth of the leaf node containing the account address can be queried from the status index storage information. For example, Figure 2 The path depth of the leaf node containing account address a1b8 is 4, which means that the storage path corresponding to this leaf node contains 4 nodes; the path depth of the leaf node containing account address af45 is 3, which means that the storage path corresponding to this leaf node contains 3 nodes.

[0084] S103. Determine the current path field of each of the target nodes.

[0085] In this embodiment, the current path field of a node can refer to field information used to indicate the current path of that node, where the current path is the addressing position of the corresponding node in the state tree. Therefore, the current path field of the target node is the current path corresponding to each node included in the data storage path. The computer device can determine the field information used to indicate the current path of each target node according to the prefix tree addressing principle.

[0086] For example, for an account with address a1b8, the depth of the leaf node containing this account can be determined from the status index storage information to be 4, indicating that the corresponding storage path contains a total of 4 nodes. According to the prefix tree addressing principle, the current path fields of these 4 nodes can be determined to be "_", "a", "a1", and "a1b" respectively.

[0087] S104. Based on the current path field, determine the physical K value corresponding to each target node in the state tree.

[0088] In this embodiment of the application, after determining the current path field of each node, the computer device can determine the physical K value corresponding to each node in the state tree.

[0089] Specifically, the computer device can retrieve the historical version information of each target node in parallel from the state index storage information, and construct the physical K value corresponding to each target node based on the historical version information and the addressing location. For example, in the example above, for the account with account address a1b8, the physical K values ​​of the four nodes contained in the storage path are <2024,_>, <2024,a>, <2023,a1>, and <2022,a1b>, respectively.

[0090] S105. Read the physical V value corresponding to the physical K value of each target node in parallel to obtain the complete storage path, and read the data through the storage path.

[0091] In this embodiment, the state index storage information stores the physical K values ​​of all nodes in the state tree, represented as KV key-value pairs. After determining the physical K values ​​of each node contained in the storage path of a certain account address, the computer device can read the physical V values ​​corresponding to the physical K values ​​of each target node from the state storage information. Storing the physical K values ​​and corresponding physical V values ​​of each node using state storage information is an existing technology in blockchain technology, and this embodiment will not elaborate on the state storage information. After determining the physical K values ​​corresponding to each node based on the state index storage information, the computer device can obtain the physical V values ​​corresponding to each physical K value from the state storage information based on the obtained physical K values.

[0092] In one possible implementation of this application, the process of the computer device reading the physical V value can be performed in parallel. That is, after determining the physical K value of each target node, the computer device can read the physical V value corresponding to each physical K value in the state storage information in parallel, and combine multiple physical V values ​​into a complete storage path for the data to be read according to the order of each target node. The above storage path can also be called a Merkel path. The computer device can quickly read the required data from the disk according to the obtained path.

[0093] For example, for account address a1b8, the physical K values ​​of the four nodes included in the storage path are <2024,_>, <2024,a>, <2023,a1>, and <2022,a1b>. The physical V values ​​corresponding to each physical K value, namely Internal_1, Internal_3, Internal_4, and Leaf_6, can be determined in parallel from the state storage information. After combining the physical V values ​​into a complete storage path according to the order of the target nodes, the path can be obtained.<Internal_1,Internal_3,Internal_4,Leaf_6> Through this path, the computer device can read the corresponding data, that is, the data stored in account address a1b8.

[0094] In this embodiment, by employing a data partitioning or disk-based storage strategy, different types of data in the blockchain can be managed specifically according to their size and / or popularity, thereby supporting parallel data reading and writing. Furthermore, by storing information through a state index to record the physical K value corresponding to each node in the state tree, the data reading process can also be executed in parallel, effectively improving the speed and efficiency of data reading and writing.

[0095] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0096] To facilitate understanding, the following examples, comparing the process with existing methods for reading blockchain state data, illustrate the complete process of reading state data using the method provided in this application.

[0097] According to the operating principle of blockchain, when a state value is updated, the entire path of that state value in the state tree (from the root node to the leaf node, also called the Merkle path) needs to be updated. Therefore, when the blockchain needs to update a certain state value, it needs to query all nodes along that path before implementing the update. This process requires reading the data from the corresponding nodes. Let's assume the data to be read is... Figure 2 Taking the data stored in the account with account address "a1b8" in the state tree shown as an example, the reading process in the prior art includes:

[0098] 1.1 The stateRoot field in the block header represents the hash value of the root node of the account state tree. The physical K of the root node can be found based on the root node hash value. Figure 2 The <2024,_> shown in the diagram represents the block height at which the current account state tree was last updated, where "2024" indicates the block height at which the current account state tree was last updated, and "_" indicates that the current path of the root node is empty.

[0099] 1.2 Based on the physical K of the root node, the physical V of the root node can be found in the ledger and deserialized to obtain the root node Internal_1. Since the address of the target account is "a1b8", the next addressing position is "a", so the addressing information at position "a" can be obtained from the data of Internal_1, and the physical K of the next addressing is <2024,a>.

[0100] 1.3 Similar to step 1.2, the intermediate node Internal_3 can be found based on the physical K <2024,a>. The next addressing position adjacent to the previous addressing position "a" is "1", so the addressing information at position "1" can be obtained from the data of the intermediate node Internal_3, and the physical K of the next addressing is <2023,a1>.

[0101] 1.4 Similar to step 1.3, the intermediate node Internal_4 can be found based on the physical K <2023,a1>. The next addressing position adjacent to the previous addressing position "1" is "b", so the addressing information at position "b" can be obtained from the data of the intermediate node Internal_4, and the physical K of the next addressing is <2022,a1b>.

[0102] 1.5, Similar to step 1.4, the node Leaf_6 can be found based on the physical K <2022,a1b>. Since the current node is a leaf node, we can check if the current leaf node contains the identifier of the target address "a1b8". If so, it means that the status value of the account with address "a1b8" has been successfully found. Therefore,<Internal_1,Internal_3,Internal_4,Leaf_6> It is a complete path through which data stored in account "a1b8" can be retrieved.

[0103] As seen in the process of reading data using existing technologies, finding the complete path to the target state value in the state tree is a serial process. This is because the physical K information of the next node needs to be constructed from the data of its parent node, which is caused by the addressing method of the prefix tree data structure. Since commonly used state trees in blockchains such as MPT and JMT are variations of prefix trees, they all suffer from the same problem: the process of reading the complete path from the root node to the target leaf node can only be performed serially, affecting data read and write efficiency.

[0104] The method provided in this application embodiment can be used to read data, and data reading can be completed efficiently by combining the data's status index storage information.

[0105] like Figure 3 The diagram shown is a schematic representation of a process for constructing a data storage path from state index storage information according to an embodiment of this application. Figure 3 The example shown could be the process of reading data from address "a1b8", that is, the process of obtaining the storage path of that address using state index information. The aforementioned state index storage information could be obtained when writing data to the account at address "a1b8" in the blockchain; that is, the state index storage information could be... Figure 2 The state index storage information corresponding to the data in the middle leaf node Leaf_6. Combined with... Figure 3 The example shown illustrates a complete process for reading data from the account with address "a1b8" using the method provided in this application embodiment:

[0106] 2.1 From the status index storage information, the depth of the leaf node containing the account "a1b8" is 4, indicating that there are a total of 4 nodes on the storage path corresponding to this leaf node. Therefore, according to the addressing principle of the prefix tree, we know that the current path fields of these 4 nodes are "_", "a", "a1" and "a1b" respectively.

[0107] 2.2 After obtaining the current path fields of the four nodes from step 2.1, the historical version information of these four nodes can be requested in parallel from the state index storage information, so that four physical K can be constructed, namely <2024,_>, <2024,a>, <2023,a1> and <2022,a1b>.

[0108] 2.3 Based on the four physical K values ​​constructed in 2.2, the physical V values ​​of the four nodes can be read in parallel from the state storage information to obtain the complete path.<Internal_1,Internal_3,Internal_4,Leaf_6> .

[0109] By comparing the above process of reading data from the same account address, the prior art requires four serial I / O operations in the state data, while the embodiments of this application only require one serial I / O and four parallel I / O operations in the state index storage information, and four parallel I / O operations in the state data. Although the total number of I / O operations increases when reading data using the method provided by the embodiments of this application, the speed of multiple parallel I / O requests is close to that of a single I / O due to the utilization of the parallel reading capability of the disk (e.g., SSD). Therefore, the overall data reading time is still better than the time overhead caused by four serial I / O operations in the prior art. In particular, considering that the maximum depth of the account state tree in the blockchain system is 40 and the maximum depth of the contract state tree is 64, compared with the multiple serial I / O reading methods in the prior art, the method provided by the embodiments of this application, which combines state index storage information and uses parallel I / O to read data, can bring greater benefits and help improve data read and write efficiency.

[0110] Reference Figure 4 The diagram illustrates a blockchain data processing device according to an embodiment of this application. Specifically, it may include a state index storage information acquisition module 401, a path depth determination module 402, a current path field determination module 403, a target K value determination module 404, a storage path determination module 405, and a data reading module 406, wherein:

[0111] The state index storage information acquisition module 401 is used to acquire the state index storage information corresponding to the data to be read when reading data stored in the blockchain according to the account address. The state index storage information is constructed in the form of KV key-value pairs and is used to store the physical K value corresponding to each node in the state tree.

[0112] The path depth determination module 402 is used to determine the path depth of the leaf node where the account address is located, wherein the path depth represents the number of target nodes contained in the storage path of the data;

[0113] The current path field determination module 403 is used to determine the current path field of each of the target nodes respectively;

[0114] The physical K-value determination module 404 is used to determine the physical K-value corresponding to each target node in the state tree based on the current path field.

[0115] The storage path determination module 405 is used to read the physical V value corresponding to the physical K value of each target node in parallel to obtain the complete storage path.

[0116] The data reading module 406 is used to read the data through the storage path.

[0117] In one possible implementation of this application embodiment, the state index storage information may be obtained when the data is written to the blockchain, and the path depth determination module 402 may specifically be used for:

[0118] Query the path depth of the leaf node containing the account address from the state index storage information.

[0119] In one possible implementation of this application embodiment, the current path field determination module 403 may specifically be used for:

[0120] Based on the prefix tree addressing principle, field information for indicating the current path of each target node is determined, wherein the current path is the addressing position of the corresponding target node in the state tree.

[0121] In one possible implementation of this application embodiment, the physical K value determination module 404 may specifically be used for:

[0122] Historical version information of each target node is obtained in parallel from the state index storage information;

[0123] Based on the historical version information and the addressing location, the physical K value corresponding to each target node is constructed.

[0124] In one possible implementation of this application embodiment, the storage path determination module 405 may specifically be used for:

[0125] The physical V values ​​corresponding to the physical K values ​​of each target node are read in parallel from the state storage information.

[0126] According to the order of each target node, the multiple physical V values ​​are combined into the complete data storage path.

[0127] In one possible implementation of this application embodiment, the above-described apparatus may further include a data storage module. Specifically, the data storage module may be used for:

[0128] The data type is determined, and each data type is configured with a corresponding disk storage path, where the disk storage path represents a disk area on the disk where the corresponding data type is stored.

[0129] According to the disk storage path, the data is stored in the corresponding disk area to achieve partitioned storage of blockchain data.

[0130] In one possible implementation of this application, each type of data may have a corresponding access frequency, and the disk storage path corresponding to different types of data may indicate disk areas on different disks; wherein, the performance of different disks may be positively correlated with the access frequency of the stored data.

[0131] This application provides a blockchain data processing apparatus, which can be a computer device that implements the relevant method steps in the foregoing method embodiments, or one or more execution units within that computer device. Accordingly, by applying this apparatus, the various steps in the foregoing method embodiments can be implemented.

[0132] As the apparatus embodiments are basically similar to the method embodiments, they are described in a relatively simple manner. For relevant details, please refer to the description in the method embodiment section.

[0133] Reference Figure 5 The diagram illustrates a computer device provided in an embodiment of this application. Figure 5 As shown, the computer device 500 in this embodiment includes: a processor 510, a memory 520, and a computer program 521 stored in the memory 520 and executable on the processor 510. When the processor 510 executes the computer program 521, it implements the steps in the various embodiments of the blockchain data processing method described above, for example... Figure 1 The steps S101 to S105 are shown. Alternatively, when the processor 510 executes the computer program 521, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 4 The functions of modules 401 to 406 are shown.

[0134] For example, the computer program 521 can be divided into one or more modules / units, which are stored in the memory 520 and executed by the processor 510 to complete this application. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which can be used to describe the execution process of the computer program 521 in the computer device 500. For example, the computer program 521 can be divided into a status index storage information acquisition module, a path depth determination module, a current path field determination module, a physical K value determination module, a storage path determination module, and a data reading module, with the specific functions of each module as follows:

[0135] The state index storage information acquisition module is used to acquire the state index storage information corresponding to the data to be read when reading data stored in the blockchain according to the account address. The state index storage information is constructed in the form of KV key-value pairs and is used to store the physical K value corresponding to each node in the state tree.

[0136] The path depth determination module is used to determine the path depth of the leaf node where the account address is located, wherein the path depth represents the number of target nodes contained in the storage path of the data;

[0137] The current path field determination module is used to determine the current path field of each of the target nodes respectively;

[0138] The physical K-value determination module is used to determine the physical K-value corresponding to each target node in the state tree based on the current path field.

[0139] The storage path determination module is used to read the physical V value corresponding to the physical K value of each target node in parallel to obtain the complete storage path.

[0140] A data reading module is used to read the data through the storage path.

[0141] The computer device 500 may be a computer device capable of implementing the relevant steps in the foregoing method embodiments. This computer device 500 may be a desktop computer, a cloud server, or other similar device. The computer device 500 may include, but is not limited to, a processor 510 and a memory 520. Those skilled in the art will understand that... Figure 5This is merely one example of computer device 500 and does not constitute a limitation on computer device 500. It may include more or fewer components than shown, or combine certain components, or different components. For example, computer device 500 may also include input / output devices, network access devices, buses, etc.

[0142] The processor 510 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0143] The memory 520 can be an internal storage unit of the computer device 500, such as a hard disk or RAM of the computer device 500. The memory 520 can also be an external storage device of the computer device 500, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the computer device 500. Furthermore, the memory 520 can include both internal and external storage units of the computer device 500. The memory 520 is used to store the computer program 521 and other programs and data required by the computer device 500. The memory 520 can also be used to temporarily store data that has been output or will be output.

[0144] This application also discloses a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the methods described in the foregoing embodiments.

[0145] This application also discloses a computer-readable storage medium storing a computer program that, when executed by a computer, implements the methods described in the foregoing embodiments.

[0146] This application also discloses a computer program product, including a computer program that, when run on a computer, causes the computer to perform the methods described in the foregoing embodiments.

[0147] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing blockchain data, characterized in that, include: When reading data stored in the blockchain based on an account address, the state index storage information corresponding to the data to be read is obtained. The state index storage information is constructed in the form of KV key-value pairs and is used to store the physical K value corresponding to each node in the state tree. The physical V value corresponding to the physical K value of each node is the information of each node. Determine the path depth of the leaf node where the account address is located, where the path depth represents the number of target nodes contained in the storage path of the data; Determine the current path field of each of the target nodes; Based on the current path field, determine the physical K value corresponding to each target node in the state tree; The physical V value corresponding to the physical K value of each target node is read in parallel in the state index storage information to obtain the complete storage path, and the data is read through the storage path. The step of determining the physical K value corresponding to each target node in the state tree based on the current path field includes: obtaining the historical version information of each target node in parallel from the state index storage information; and constructing the physical K value corresponding to each target node based on the historical version information and the current path.

2. The method according to claim 1, characterized in that, The state index storage information is obtained when the data is written to the blockchain, and determining the path depth of the leaf node where the account address is located includes: Query the path depth of the leaf node containing the account address from the state index storage information.

3. The method according to claim 1, characterized in that, The step of determining the current path field of each of the target nodes includes: Based on the prefix tree addressing principle, field information for indicating the current path of each target node is determined, wherein the current path is the addressing position of the corresponding target node in the state tree.

4. The method according to any one of claims 1 to 3, characterized in that, The parallel reading of the physical K value corresponding to each target node in the state index storage information and the corresponding physical V value to obtain the complete storage path includes: The physical V value corresponding to the physical K value of each target node is read in parallel from the state index storage information. According to the order of each target node, the multiple physical V values ​​are combined into the complete data storage path.

5. The method according to any one of claims 1 to 3, characterized in that, Before obtaining the status index storage information corresponding to the data to be read, the process also includes: The data type is determined, and each data type is configured with a corresponding disk storage path, where the disk storage path represents a disk area on the disk where the corresponding data type is stored. According to the disk storage path, the data is stored in the corresponding disk area to achieve partitioned storage of blockchain data.

6. The method according to claim 5, characterized in that, Each type of data has a corresponding access frequency, and the disk storage path corresponding to different types of data indicates a disk area on a different disk; wherein, the performance of different disks is positively correlated with the access frequency of the stored data.

7. A blockchain data processing device, characterized in that, include: The state index storage information acquisition module is used to acquire the state index storage information corresponding to the data to be read when reading data stored in the blockchain according to the account address. The state index storage information is constructed in the form of KV key-value pairs and is used to store the physical K value corresponding to each node in the state tree. The physical V value corresponding to the physical K value of each node is the information of each node. The path depth determination module is used to determine the path depth of the leaf node where the account address is located, wherein the path depth represents the number of target nodes contained in the storage path of the data; The current path field determination module is used to determine the current path field of each of the target nodes respectively; The physical K-value determination module is used to determine the physical K-value corresponding to each target node in the state tree based on the current path field. The storage path determination module is used to read in parallel the physical V value corresponding to the physical K value of each target node in the state index storage information to obtain the complete storage path. A data reading module is used to read the data through the storage path; Specifically, the physical K-value determination module is used to: obtain the historical version information of each target node in parallel from the state index storage information; and construct the physical K-value corresponding to each target node based on the historical version information and the current path.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it causes the computer device to implement the method as described in any one of claims 1 to 6.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is run, the method as described in any one of claims 1 to 6 is performed.

Images