Block chain data processing method and device and computer equipment
By introducing a state tree index mechanism to read data in parallel, the problem of slowing down reading and writing speed caused by the expansion of ledger data in the blockchain is solved, and the data reading and writing efficiency is significantly improved.
Patent Information
- Application Number
- CN202411659037.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-19
- Publication Date
- 2025-03-14
- Estimated Expiration
- 2044-11-19
AI Technical Summary
The expansion of ledger data in blockchain causes the speed of reading and writing data to slow down, especially when the depth of the state tree increases, the number of IO times per data reading increases, seriously affecting the reading and writing efficiency.
By introducing a state tree indexing mechanism in the blockchain, the state index storage information is obtained when reading data, the path depth of the leaf node where the account address is located, and the physical V value corresponding to the physical K value of the target node is read in parallel, and a complete storage path is constructed to read the data.
By reading data in parallel, the time to build storage paths is reduced, and the read and write efficiency of blockchain data is improved, especially when the data volume is large and the state tree depth is large.
Smart Images

Figure CN119620939A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application belong to the field of blockchain and data processing technology, and in particular, to a method, device and computer equipment for processing blockchain data. Background Art
[0002] Ledger expansion is one of the main issues that affect blockchain performance. As the amount of ledger data continues to increase, the ever-expanding ledger will affect the speed at which the blockchain reads and writes data.
[0003] Specifically, at the data writing level, each blockchain node needs to save multiple types of data, such as block data, index data, status data, snapshot data, log data, etc. In the related art, using a single disk to save the above multiple types of data is prone to problems such as excessive single disk write load and affected data writing speed due to excessive data volume.
[0004] At the data reading level, one of the main factors affecting the performance of blockchain nodes is the speed of reading blockchain status data. In related technologies, the status tree is the main structure for storing blockchain status data. The process of reading a target value in the blockchain status tree is to read from the root node of the status tree layer by layer from top to bottom until the leaf node. This process is serial. Since each read of a node corresponds to a disk input / output (IO), as the blockchain ledger data continues to expand, the average depth of the status tree gradually increases, and the average IO number of each read data will also continue to increase, resulting in a continuous increase in the total time of data reading, which seriously affects the efficiency of data reading. Summary of the invention
[0005] In view of this, the embodiments of the present application provide a method, apparatus and computer device for processing blockchain data to improve the efficiency of reading and writing blockchain data.
[0006] A first aspect of an embodiment of the present application provides a method for processing blockchain data, including:
[0007] When reading data stored in the blockchain according to the account address, the state index storage information corresponding to the data to be read is obtained, and the state index storage information is constructed in the form of a KV key-value pair, which 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 included in the storage path of the data;
[0009] Determine the current path field of each target node respectively;
[0010] Based on the current path field, determine the physical K value corresponding to each of the target nodes in the state tree;
[0011] The physical V values corresponding to the physical K values corresponding to the target nodes are read in parallel to obtain the complete storage path, and the data is read through the storage path.
[0012] In a possible implementation manner of an embodiment of the present application, the state index storage information is stored when the data is written into the blockchain, and the determining the path depth of the leaf node where the account address is located includes:
[0013] The path depth of the leaf node where the account address is located is queried from the status index storage information.
[0014] In a possible implementation manner of the embodiment of the present application, the respectively determining the current path field of each of the target nodes includes:
[0015] According to the prefix tree addressing principle, field information for indicating the current path of each target node is determined respectively, and the current path is the addressing position of the corresponding target node in the status tree.
[0016] In a possible implementation manner of the embodiment of the present application, determining the physical K value corresponding to each of the target nodes in the state tree based on the current path field includes:
[0017] Acquire historical version information of each of the target nodes in parallel from the state index storage information;
[0018] According to the historical version information and the addressing position, a physical K value corresponding to each of the target nodes is constructed.
[0019] In a possible implementation of the embodiment of the present application, the parallel reading of the physical V values corresponding to the physical K values corresponding to the target nodes to obtain the complete storage path includes:
[0020] Read in parallel the physical V value corresponding to the physical K value corresponding to each of the target nodes in the state storage information;
[0021] According to the order of each of the target nodes, the multiple physical V values are combined into a complete storage path for the data.
[0022] In a possible implementation manner of the embodiment of the present application, before acquiring the state index storage information corresponding to the data to be read, the method further includes:
[0023] Determine the type of the data, any type of data is configured with a corresponding disk storage path, and the disk storage path represents a disk area on the disk that stores data of the corresponding type;
[0024] According to the disk storage path, the data is stored in the corresponding disk area to realize the partitioned storage of blockchain data.
[0025] In a possible implementation of an embodiment of the present application, each type of data has a corresponding access frequency, and the disk storage paths corresponding to different types of data indicate 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 an embodiment of the present application provides a blockchain data processing device, including:
[0027] A state index storage information acquisition module is used to obtain the state index storage information corresponding to the data to be read when reading the 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] A path depth determination module, 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 included in the storage path of the data;
[0029] A current path field determination module, used to respectively determine the current path field of each target node;
[0030] A physical K value determination module, used to determine the physical K value corresponding to each of the target nodes in the state tree based on the current path field;
[0031] A storage path determination module, used for reading in parallel the physical V values corresponding to the physical K values corresponding to the target nodes, 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 an embodiment of the present application provides a computer device, comprising 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 implements a method as described in any one of the first aspects above.
[0034] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a computer, the method described in any one of the first aspects above is implemented.
[0035] A fifth aspect of the embodiments of the present application provides a computer program product, including a computer program, which, when executed, enables the method described in any one of the first aspects to be executed.
[0036] Compared with the prior art, the embodiments of the present application have the following beneficial effects:
[0037] The embodiment of the present application can construct state index storage information that can store the physical K value corresponding to each node in the state tree in the form of KV key-value pairs when data is written into the blockchain or data is generated during the operation of the blockchain, so that when reading the relevant data stored in the blockchain according to the account address, the state index storage information corresponding to the data can be obtained to achieve efficient reading and writing of data. Specifically, the embodiment of the present application can obtain 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, so that after determining the current path field of each target node respectively, the physical K value corresponding to each target node in the state tree can be determined based on the current path field, and then the physical V value corresponding to the physical K value corresponding to each target node can be read in parallel to obtain the complete storage path of the data to be read, that is, the Merkel path. By introducing the state tree index mechanism, the embodiment of the present application can construct the keys of all tree nodes on the Merkel path at one time based on the information of the target key and the state tree index when reading the Merkel path. In this way, when a request for parallel reading of the Merkle path is initiated on the disk, the construction time of the Merkle path can be reduced on a disk that supports parallel reading (such as a solid-state drive SSD), thereby increasing the efficiency and speed of reading data based on the Merkle path. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or prior art descriptions. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0039] Figure 1 It is a schematic diagram of a method for processing blockchain data provided by an embodiment of the present application;
[0040] Figure 2 is a schematic diagram of a state tree provided in an embodiment of the present application;
[0041] Figure 3 It is a schematic diagram of a process of constructing a storage path of data from state index storage information provided by an embodiment of the present application;
[0042] Figure 4 It is a schematic diagram of a blockchain data processing device provided in an embodiment of the present application;
[0043] Figure 5 It is a schematic diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0044] In the following description, specific details such as specific system structures, technologies, etc. are proposed for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from hindering the description of the present application.
[0045] The blockchain system will generate various types of data during operation. For example, block data, status data, index data, snapshot data, log data, etc. In addition, the data nodes in the blockchain (nodes holding the full amount of historical data) also need to save archived data. The importance and popularity of these data vary. If the data is not partitioned in a refined manner, and the same disk or even the same storage engine is used to store different types of data, it is easy to cause the read and write load of a single disk to be too high. Especially in blockchain systems that need to process a high number of transactions per second (TPS), a single disk will significantly reduce the read and write speed of data. In addition, due to the limited capacity of a single disk, it is difficult to achieve vertical expansion of storage space by using a single disk to store various types of data.
[0046] In addition, currently common blockchain systems all use the state tree as a data structure for storing the historical status of accounts and contracts. Representative state trees include the MPT (Merkle Patricia Tree) tree used by Ethereum and the JMT (Jellyfish Merkle Tree) tree used by Aptos. The conventional way to read the blockchain state tree is to read from the root node of the tree layer by layer from top to bottom until the target leaf node is obtained at the bottom of the state tree. Since each node in the blockchain state tree corresponds to a key-value (KV) pair of data in the blockchain ledger, reading a node in the state tree actually corresponds to a disk IO. As the blockchain ledger data continues to expand, the average depth of the state tree gradually increases, and the average IO times for each data read will also increase, resulting in a continuous increase in the total time for data reading, which seriously affects the efficiency of data reading and writing.
[0047] In response to the above problems, the embodiment of the present application provides a method for processing blockchain data, which can store the data of each node of the blockchain in separate disks according to the data volume and / or data hotness of different types of data, so as to achieve the purpose of supporting parallel writing, supporting vertical expansion and reducing hardware costs. On this basis, the embodiment of the present application also introduces a state tree index mechanism. When reading the storage path of the data, based on the information of 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 one time, thereby initiating a request to read the storage path in parallel on the disk, reducing the time to build the path and improving the overall read and write efficiency of blockchain data.
[0048] The technical solution of the present application is described below through specific embodiments.
[0049] Reference Figure 1 , which shows a schematic diagram of a blockchain data processing method provided by an embodiment of the present 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, wherein the state index storage information is constructed in the form of a KV key-value pair 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, and the execution subject of this method can be a computer device connected to the blockchain system, that is, the computer device can achieve efficient data reading and writing by executing each step of this method. The above-mentioned computer device can be a desktop computer connected to the blockchain system, such as a desktop computer or an all-in-one computer, or a cloud server or other device. The specific type of the computer device is not limited in this embodiment of the application.
[0052] In an embodiment of the present application, the data to be read may be blockchain data, that is, data stored in the blockchain.
[0053] In order to facilitate a better understanding of the embodiments of the present application, the data storage process, that is, the process of writing data in the blockchain, is first introduced.
[0054] In an embodiment of the present application, a computer device may write data to a blockchain by using a partition or disk management strategy according to different types of data. Among them, data disk management may refer to using multiple disks to store data, and each type of data is stored on a different disk after being written into the blockchain, and different types of data are stored on different disks. Therefore, for different types of data, a computer device may pre-configure a corresponding disk storage path for each type of data, and the disk storage path may be used to indicate a disk area on the disk where data of the corresponding type is stored. Exemplarily, a disk storage path configured for a certain type of data data A may be a storage path of disk A, which may indicate that data data A of this type will be stored in disk A after being written into the blockchain; a disk storage path configured for another type of data data B may be a storage path in disk B, which indicates that data data B of this type will be stored in disk B after being written into the blockchain.
[0055] Therefore, when a computer device writes data to a 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 disk areas on different disks, the data can be stored in the corresponding disk area according to the disk storage paths corresponding to the type of data, thereby realizing partitioned storage of blockchain data.
[0056] In a possible implementation of the embodiment of the present application, according to the data required and generated during the operation of the blockchain system, the blockchain data can be divided into multiple types in advance, and these different types of data can be partitioned and stored in a targeted manner.
[0057] In the embodiment of the present application, each type of data may have a corresponding access frequency, and the access frequency may indicate how frequently the data is read and written.
[0058] As shown in Table 1, this is an example of the type classification of blockchain data provided in an embodiment of the present application, as well as 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 archive data. Among them, archive data is data unique to data nodes in the blockchain. The data volume and access frequency of these six types of data are not exactly the same. Specifically, from the perspective of data volume, the amount of archive data is the largest, and the amount of other data such as logs and consensus messages is the smallest. In addition, the amount of block data is also large, the amount of state data is usually smaller than that of block data, and the amount of index data and snapshot data is relatively small. In terms of access frequency, the state data is accessed most frequently, the access frequency of snapshot data is also relatively high, the access frequency of block data and index data is relatively moderate, the access frequency of archive data is low, and the access frequency of other data such as logs and consensus messages is even lower.
[0062] Of course, the classification shown in Table 1 is only an example provided in the embodiment of the present application. In different scenarios, other classification methods can be adopted according to actual needs, and the embodiment of the present application is not limited to this.
[0063] Still taking the classification shown in Table 1 as an example, after the blockchain data is classified based on the above method, it can be partitioned or stored in separate disks according to different types of data when writing data to form blockchain data partitions.
[0064] In a possible implementation of the embodiment of the present application, the performance of different disks may be positively correlated with the access frequency of the stored data. For example, the higher the access frequency of the data, the better the performance of the disk can be used to store the corresponding data. Therefore, the embodiment of the present application can use different disks to store different types of data according to the access frequency of the data, thereby achieving differentiated configuration according to the hotness and coldness of the data.
[0065] For example, since the access frequency of block data, index data, archive data and other data is relatively moderate or low, low-performance and high-capacity HDD disks can be used to store these types of data; while for data with higher access frequency such as status data and snapshot data, high-performance and large-capacity SSD disks can be used for storage. Among them, HDD is a mechanical hard disk that relies on rotating disk platters to store data, and can read and write data through a magnetic head. SSD is a solid-state hard disk that uses flash memory chips as storage media. Data can be stored directly on semiconductor chips without mechanical movement. The read and write speed of HDD is slow. Due to the limitation of disk rotation speed, the random read and write speed is slow, which is suitable for sequential reading and writing of large amounts of data. The read and write speed of SSD is much higher than that of HDD, and it performs well in random read and write. Daily operations such as system startup and program loading can be faster and smoother.
[0066] In an embodiment of the present application, after storing the data in the aforementioned manner, the computer device may form state index storage information of the stored or written data. The above state index storage information may be stored when the data is written to the blockchain, and the state index storage information may be constructed in the form of a KV key-value pair, which is used to store the physical K value corresponding to each node in the state tree. The state tree is a data structure used to store the historical status of accounts and contracts in a blockchain system, including the MPT tree used by Ethereum, the JMT tree used by Aptos, etc.
[0067] In a possible implementation of the embodiment of the present application, for a state tree of the JMT tree type, the state index storage information may include the following content:
[0068] <Contract address + current path>-><historical version>
[0069] <Contract address + full path>-><path depth>
[0070] Among them, "current path" can refer to the addressing position of the current node of the blockchain in the state tree. "Full path" can refer to the hexadecimal encoding of the account address in the account state tree, and can refer to the hexadecimal encoding of the contract storage slot in the contract state tree. "Path depth" indicates the depth of the leaf node where the target account or target contract storage slot is located 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. The historical version indicates the block height at which the current node was last updated. In the state index storage information, for the account state tree, the contract address can be omitted.
[0071] As shown in Figure 2, this is an example of a state tree provided in an embodiment of the present application. Figure 2 In the status tree shown, each node in the tree corresponds to a KV key-value pair data stored on the physical disk. Among them, the physical K value is composed of three variables: <historical version>, <contract address>, and <current path>. The historical version indicates the block height at which the subtree with the current node as the root was last updated; the contract address is only used in the contract status tree, indicating the hexadecimal encoding value of the contract address; the current path indicates the addressing position of the current node in the status tree, the account status tree can be addressed according to the hexadecimal encoding of the account address as the complete path, and the contract status tree can be addressed according to the hexadecimal encoding of the contract storage slot as the complete path. The physical V value represents the data obtained after the tree node is serialized.
[0072] exist Figure 2 In the state tree shown, the state values of the account or contract are stored in the leaf nodes of the tree. For example, Figure 2The leaf node Leaf_2 stores the data of account address 10bc, the leaf node Leaf_5 stores the data of account address af45, the leaf node Leaf_6 stores the data of account address a1b8, and the leaf node Leaf_7 stores the data of account address a15d.
[0073] After writing data to the blockchain, or 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 subsequently.
[0074] For example, 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> , which means that when reading the data in the account address a1b8 corresponding to the leaf node Leaf_6, the complete path is the four nodes Internal_1, Internal_3, Internal_4 and Leaf_6. Figure 2 As shown in the figure, the depth of the path is 4, indicating that there are 4 nodes on the path, and the physical K values corresponding to each node are <2024,_>, <2024,a>, <2023,a1>, and <2022,a1b>. Correspondingly, the physical V value corresponding to the physical K value of each node is 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 the account address a1b8 can be constructed as follows:
[0076] Path depth of target account a1b8: 4
[0077] The first physical K: <2024,_>;
[0078] The second physical K: <2024,a>;
[0079] The third physical K: <2023,a1>;
[0080] The fourth physical K: <2022,a1b>;
[0081] When a computer device reads data stored in an account on the blockchain according to the account address, it can obtain the corresponding status 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 included in the storage path of the data.
[0083] In an embodiment of the present application, the path depth of the leaf node where the account address is located can be queried from the state index storage information. For example, Figure 2 The path depth of the leaf node where the account address a1b8 is located is 4, which means that the number of nodes contained in the storage path corresponding to the leaf node is 4; the path depth of the leaf node where the account address af45 is located is 3, which means that the number of nodes contained in the corresponding storage path is 3.
[0084] S103: Determine the current path field of each target node respectively.
[0085] In the embodiment of the present application, the current path field of a node may refer to field information used to indicate the current path of the node, and 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 contained 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 an address of a1b8, it can be determined from the state index storage information that the depth of the leaf node where the account is located is 4, indicating that the corresponding storage path contains a total of 4 nodes. According to the prefix tree addressing principle, it can be determined that the current path fields of these 4 nodes are "_", "a", "a1" and "a1b" respectively.
[0087] S104. Determine the physical K value corresponding to each of the target nodes in the status tree based on the current path field.
[0088] In an embodiment of the present 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 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 according to the historical version information and the addressing position. For example, in the above example, for the account with the 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> respectively.
[0090] S105 . Read the physical V values corresponding to the physical K values corresponding to the target nodes in parallel to obtain the complete storage path, and read the data through the storage path.
[0091] In an embodiment of the present application, the state index storage information stores the physical K values of all nodes in the state tree represented in the form of 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 value corresponding to the physical K value corresponding to each target node from the state storage information. Among them, using state storage information to store the physical K value and the corresponding physical V value of each node belongs to the existing technology in blockchain technology, and the embodiment of the present application does not elaborate on the state storage information. After determining the physical K value corresponding to each node based on the state index storage information, the computer device can obtain the physical V value corresponding to each physical K value from the state storage information according to the obtained physical K value.
[0092] In a possible implementation of an embodiment of the present application, the process of a computer device reading a physical V value may be performed in parallel, that is, after determining the physical K value of each target node, the computer device may 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 in the order of each target node. The above storage path may also be referred to as a Merkel path. The computer device may quickly read the required data from the disk according to the obtained path.
[0093] For example, for the account with 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> respectively. The physical V value corresponding to each physical K value can be determined in parallel from the state storage information, namely Internal_1, Internal_3, Internal_4 and Leaf_6. After combining the physical V values into a complete storage path in 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 the account address a1b8.
[0094] In the embodiment of the present application, through data partitioning or disk storage strategy, different types of data in the blockchain can be managed in a targeted manner according to the size of the data and / or the degree of hotness and coldness of the data, thereby supporting parallel reading and writing of data. On this basis, the physical K value corresponding to each node in the state tree is recorded through the state index storage information, so that 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 size of the serial numbers of the steps in the above embodiments does not mean 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 the present application.
[0096] For ease of understanding, the following is a comparison between a specific example and an existing process of reading blockchain status data to illustrate the complete process of reading status data using the method provided in the embodiment of the present application.
[0097] According to the operating principle of blockchain, when a state value is updated, the entire path of this 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 state value, it needs to query all the nodes on the path and then implement the update. This process also requires reading the data in the corresponding node. Assume that the data to be read is Figure 2 Taking the data stored in the account with the account address "a1b8" in the status tree as an example, the reading process in the prior art includes:
[0098] 1.1, the stateRoot field of the block header represents the root node hash value of the account state tree. According to the root node hash value, the physical K of the root node can be found, that is, Figure 2 As shown in <2024,_>, “2024” indicates the block height where the current account status tree was last updated, and “_” indicates that the current path of the root node is empty.
[0099] 1.2, according to the physical K of the root node, the physical V of the root node can be found on 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 in the data of Internal_1, and the next addressing physical K 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 in the data of the intermediate node Internal_3, and the next addressing physical K 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 in the data of the intermediate node Internal_4, and the next addressing physical K 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 whether the current leaf node contains the identifier of the target address "a1b8". If so, it means that the status value of the account with the address "a1b8" has been successfully found. Therefore,<Internal_1,Internal_3,Internal_4,Leaf_6> It is a complete path, through which the data stored in the account "a1b8" can be read.
[0103] From the above process of reading data using the existing technology, it can be seen that finding the complete path of the target state value in the state tree is a serial process. The essence of this is that 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 the commonly used state trees of blockchains such as MPT and JMT are variants of the prefix tree, they all have the same problem, that is, the process of reading the complete path from the root node to the target leaf node can only be performed serially, which affects the efficiency of data reading and writing.
[0104] By using the method provided in the embodiment of the present application to read data, the data status index storage information can be combined to efficiently complete the data reading.
[0105] like Figure 3 FIG. 1 is a schematic diagram of a process of constructing a storage path of data from state index storage information provided by an embodiment of the present application. Figure 3 The example shown can be the process of reading data at the address "a1b8", that is, the process of obtaining the storage path of the address through the state index information. The above state index storage information can be stored when writing data to the account at the address "a1b8" in the blockchain, that is, the state index storage information can be Figure 2 The state index storage information corresponding to the data in the leaf node Leaf_6. Figure 3 In the example shown, the complete process of reading data in the account with the address "a1b8" using the method provided in the embodiment of the present application can be:
[0106] 2.1, from the state index storage information, the depth of the leaf node where the "a1b8" account is located is 4, which means that there are 4 nodes in the storage path corresponding to the leaf node. Therefore, according to the addressing principle of the prefix tree, it can be known 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 in step 2.1, the historical version information of the four nodes can be requested in parallel in the state index storage information, so four physical Ks can be constructed, namely <2024,_>, <2024,a>, <2023,a1> and <2022,a1b>.
[0108] 2.3, according to the 4 physical K values constructed in 2.2, the physical V of the 4 nodes can be read in parallel from the state storage information to obtain the complete path, that is,<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 needs to execute four serial IOs in the state data, while the embodiment of the present application only needs to execute one serial IO and four parallel IOs in the state index storage information, and execute four parallel IOs in the state data. Although the total number of IOs in the whole process is increased by using the method provided by the embodiment of the present application to read data, due to the use of the parallel reading capability of the disk (for example, it can be an SSD), the speed of multiple parallel IO requests is close to that of a single IO, so the overall data reading time is still better than the time overhead caused by four serial IOs 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 reading method of multiple serial IOs in the prior art, the method provided by the embodiment of the present application is used in combination with the state index storage information to read data through parallel IO, which can bring greater benefits and help improve the reading and writing efficiency of data.
[0110] Reference Figure 4 , shows a schematic diagram of a blockchain data processing device provided by an embodiment of the present application, which may specifically 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 obtain the state index storage information corresponding to the data to be read when reading the 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] A path depth determination module 402, 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 included 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 target node respectively;
[0114] A physical K value determination module 404, configured to determine the physical K value corresponding to each of the target nodes in the state tree based on the current path field;
[0115] A storage path determination module 405 is used to read in parallel the physical V value corresponding to the physical K value corresponding to each target node to obtain the complete storage path;
[0116] The data reading module 406 is configured to read the data through the storage path.
[0117] In a possible implementation of the embodiment of the present application, the state index storage information may be stored when the data is written into the blockchain, and the path depth determination module 402 may be specifically used to:
[0118] The path depth of the leaf node where the account address is located is queried from the status index storage information.
[0119] In a possible implementation of the embodiment of the present application, the current path field determination module 403 may be specifically used to:
[0120] According to the prefix tree addressing principle, field information for indicating the current path of each target node is determined respectively, and the current path is the addressing position of the corresponding target node in the status tree.
[0121] In a possible implementation of the embodiment of the present application, the physical K value determination module 404 may be specifically used to:
[0122] Acquire historical version information of each of the target nodes in parallel from the state index storage information;
[0123] According to the historical version information and the addressing position, a physical K value corresponding to each target node is constructed.
[0124] In a possible implementation of the embodiment of the present application, the storage path determination module 405 may be specifically used to:
[0125] Read in parallel the physical V value corresponding to the physical K value corresponding to each of the target nodes in the state storage information;
[0126] According to the order of each of the target nodes, the multiple physical V values are combined into a complete storage path for the data.
[0127] In a possible implementation of the embodiment of the present application, the above device may further include a data storage module. The data storage module may be specifically used for:
[0128] Determine the type of the data, any type of data is configured with a corresponding disk storage path, and the disk storage path represents a disk area on the disk that stores data of the corresponding type;
[0129] According to the disk storage path, the data is stored in the corresponding disk area to realize the partitioned storage of blockchain data.
[0130] In a possible implementation of an embodiment of the present application, each type of data may have a corresponding access frequency, and the disk storage paths 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] The present application provides a blockchain data processing device, which can be a computer device that implements the relevant method steps in the aforementioned method embodiments, or one or more execution units in the computer device. Accordingly, the device can be used to implement the various steps in the aforementioned method embodiments.
[0132] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment part.
[0133] Reference Figure 5 , shows a schematic diagram of a computer device provided by an embodiment of the present application. Figure 5 As shown, the computer device 500 in the embodiment of the present application 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, the steps in each embodiment of the above-mentioned blockchain data processing method are implemented, such as Figure 1 Alternatively, when the processor 510 executes the computer program 521, the functions of each module / unit in the above-mentioned device embodiments are realized, for example Figure 4 Functions of modules 401 to 406 are shown.
[0134] Exemplarily, the computer program 521 may be divided into one or more modules / units, which are stored in the memory 520 and executed by the processor 510 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which may be used to describe the execution process of the computer program 521 in the computer device 500. For example, the computer program 521 may be divided into a state 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, and the specific functions of each module are as follows:
[0135] A state index storage information acquisition module is used to obtain the state index storage information corresponding to the data to be read when reading the 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] A path depth determination module, 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 included in the storage path of the data;
[0137] A current path field determination module, used to respectively determine the current path field of each target node;
[0138] A physical K value determination module, used to determine the physical K value corresponding to each of the target nodes in the state tree based on the current path field;
[0139] A storage path determination module, used for reading in parallel the physical V values corresponding to the physical K values corresponding to the target nodes, 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 above-mentioned various method embodiments, and the computer device 500 may be a desktop computer, a cloud server, etc. 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 only an example of the computer device 500 and does not constitute a limitation of the computer device 500. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the computer device 500 may also include input and output devices, network access devices, buses, etc.
[0142] The processor 510 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.
[0143] The memory 520 may be an internal storage unit of the computer device 500, such as a hard disk or memory of the computer device 500. The memory 520 may also be an external storage device of the computer device 500, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device 500. Further, the memory 520 may also include both an internal storage unit of the computer device 500 and an external storage device. 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 may also be used to temporarily store data that has been output or is to be output.
[0144] An embodiment of the present application further discloses a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the methods described in the above embodiments are implemented.
[0145] The embodiments of the present application further disclose a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a computer, the methods described in the above embodiments are implemented.
[0146] The embodiments of the present application further disclose a computer program product, including a computer program. When the computer program is run on a computer, the computer is enabled to execute the methods described in the aforementioned embodiments.
[0147] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application is described in detail with reference to the above-mentioned embodiments, a person skilled in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.
Claims
1. A method for processing blockchain data, characterized in that: include: When reading data stored in the blockchain according to the account address, the state index storage information corresponding to the data to be read is obtained, and the state index storage information is constructed in the form of a KV key-value pair, which is used to store the physical K value corresponding to each node in the state tree; Determine the path depth of the leaf node where the account address is located, where the path depth represents the number of target nodes included in the storage path of the data; Determine the current path field of each target node respectively; Based on the current path field, determine the physical K value corresponding to each of the target nodes in the state tree; The physical V values corresponding to the physical K values corresponding to the target nodes are read in parallel to obtain the complete storage path, and the data is read through the storage path.
2. The method according to claim 1, characterized in that The state index storage information is stored when the data is written into the blockchain, and the determining the path depth of the leaf node where the account address is located includes: The path depth of the leaf node where the account address is located is queried from the status index storage information.
3. The method according to claim 1 or 2, characterized in that: The respectively determining the current path field of each target node includes: According to the prefix tree addressing principle, field information for indicating the current path of each target node is determined respectively, and the current path is the addressing position of the corresponding target node in the status tree.
4. The method according to claim 3, characterized in that The determining, based on the current path field, a physical K value corresponding to each of the target nodes in the state tree includes: Acquire historical version information of each of the target nodes in parallel from the state index storage information; According to the historical version information and the addressing position, a physical K value corresponding to each of the target nodes is constructed.
5. The method according to any one of claims 1, 2 or 4, characterized in that: The parallel reading of the physical V value corresponding to the physical K value corresponding to each of the target nodes to obtain the complete storage path includes: Read in parallel the physical V value corresponding to the physical K value corresponding to each of the target nodes in the state storage information; According to the order of each of the target nodes, the multiple physical V values are combined into a complete storage path for the data.
6. The method according to any one of claims 1, 2 or 4, characterized in that: Before acquiring the state index storage information corresponding to the data to be read, the method further includes: Determine the type of the data, any type of data is configured with a corresponding disk storage path, and the disk storage path represents a disk area on the disk that stores data of the corresponding type; According to the disk storage path, the data is stored in the corresponding disk area to realize the partitioned storage of blockchain data.
7. The method according to claim 6, characterized in that Each type of data has a corresponding access frequency, and the disk storage paths corresponding to different types of data indicate disk areas on different disks; wherein the performance of different disks is positively correlated with the access frequency of the stored data.
8. A blockchain data processing device, characterized in that: include: A state index storage information acquisition module is used to obtain the state index storage information corresponding to the data to be read when reading the 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; A path depth determination module, 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 included in the storage path of the data; A current path field determination module, used to respectively determine the current path field of each target node; A physical K value determination module, used to determine the physical K value corresponding to each of the target nodes in the state tree based on the current path field; A storage path determination module, used for reading in parallel the physical V values corresponding to the physical K values corresponding to the target nodes, to obtain the complete storage path; A data reading module is used to read the data through the storage path.
9. 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, the computer device is caused to implement the method according to any one of claims 1 to 7.
10. A computer program product, comprising a computer program, characterized in that When the computer program is executed, the method according to any one of claims 1 to 7 is executed.
Citation Information
Patent Citations
Block chain state data caching and querying method and device, and storage medium
CN110175188A
Efficient and credible indexing method for block chain data
CN114020737A
Block chain state data storage method, synchronization method and storage medium
CN118131998A
Method for constructing world state based on Merkel dictionary tree and computer equipment
CN118939653A
Concurrent access methods for tree data structures
US20140074841A1
Cited By
Project audit management system and method based on big data
CN119887126A
A project audit management system and method based on big data
CN119887126B