Transaction data storage method and device, computer device and storage medium

Abstract

This application discloses a transaction data storage method. The method includes: acquiring transaction data from a blockchain block; parsing the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data; querying whether a first root hash value of a first slave IAVL tree corresponding to the contract address exists in the main IAVL tree; if the first root hash value exists in the main IAVL tree, opening the first slave IAVL tree based on the first root hash value; calculating the hash value of the key value in the key-value pair, and concatenating the contract address with the hash value to obtain a new key value; combining the new key value with the value value in the key-value pair to form first data to be stored, and inserting the first data to be stored into the first slave IAVL tree. This application can reduce the probability of IAVL tree subtree height imbalance, reduce the number of self-balancing triggers, and reduce server computing and storage resource consumption.

Description

Technical Field

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

[0002] For blockchain applications developed based on the Cosmos framework, the underlying data storage uses an IAVL tree. When a smart contract is called to process a user's transaction data, the key-value pairs in the transaction data are stored as key-value pairs on the underlying IAVL tree.

[0003] However, the inventors discovered that the existing storage rules on IAVL trees are as follows: the corresponding key is the hash of the data key value concatenated with the contract address, and the corresponding value is the data value. Therefore, transaction data within the same contract has the same prefix (contract address) on the IAVL tree. According to the characteristics of IAVL trees, the stored data will fall on the same subtree. Under this Cosmos framework, if a contract has a large amount of data that needs to be stored, this data will be inserted into the same subtree of the IAVL tree. This will frequently cause the height difference of the current subtree to become unbalanced in the entire IAVL tree, triggering the IAVL tree self-balancing action, consuming a large amount of server computing and storage resources, and reducing the blockchain storage performance. Summary of the Invention

[0004] In view of this, a transaction data storage method, apparatus, computer equipment, and computer-readable storage medium are provided to solve the problem that in the prior art, when storing transaction data in blockchain applications developed through the Cosmos framework, the height difference of the subtrees of the IAVL tree frequently becomes unbalanced across the entire IAVL tree, triggering the IAVL tree self-balancing action, consuming a large amount of server computing and storage resources, and reducing the performance of blockchain storage.

[0005] This application provides a method for storing transaction data, including:

[0006] Retrieve transaction data from blocks in the blockchain;

[0007] The transaction data is parsed to obtain the contract address and key-value pairs corresponding to the transaction data;

[0008] Check if the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree;

[0009] If the first root hash value exists in the main IAVL tree, then the first slave IAVL tree is opened according to the first root hash value;

[0010] Calculate the hash value of the key in the key-value pair, and concatenate the contract address with the hash value to obtain a new key value;

[0011] The new key value and the value in the key-value pair are combined to form the first data to be stored, and the first data to be stored is inserted into the first IAVL tree.

[0012] Optionally, after the step of inserting the first data to be stored into the first IAVL tree, the method further includes:

[0013] Calculate the second root hash value of the first IAVL tree, and update the first root hash value stored in the main IAVL tree with the second hash value;

[0014] Calculate the third root hash value of the main IAVL tree.

[0015] Optionally, the method further includes:

[0016] If the first hash value does not exist in the main IAVL tree, then the contract address is determined to belong to a new contract address;

[0017] Create a second IAVL tree corresponding to the new contract address;

[0018] Calculate the hash value of the key value in the key-value pair, and concatenate the new contract address with the hash value to obtain the concatenated key value;

[0019] The concatenated key value and the value in the key-value pair are combined to form the second data to be stored, and the second data to be stored is inserted into the second IAVL tree.

[0020] Optionally, the method further includes:

[0021] Calculate the fourth root hash value of the second IAVL tree, and combine the new contract address and the fourth root hash value to form the third data to be stored, wherein the new contract address is used as the key value in the third data to be stored, and the fourth hash value is used as the value value in the third data to be stored.

[0022] Insert the third data to be stored into the main IAVL tree;

[0023] Calculate the fifth root hash value of the main IAVL tree.

[0024] Optionally, calculating the hash value of the key in the key-value pair includes:

[0025] The hash value of the key in the key-value pair is calculated using a preset hash algorithm.

[0026] Optionally, before parsing the transaction data, the method further includes:

[0027] The signature information of the sender of the transaction data is verified.

[0028] Optionally, the method further includes:

[0029] The first IAVL tree checks whether its own balance has been broken. If the first IAVL tree's own balance has been broken, a self-balancing action is triggered.

[0030] This application also provides a transaction data storage device, comprising:

[0031] The acquisition module is used to acquire transaction data from blocks in the blockchain;

[0032] The parsing module is used to parse the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data;

[0033] The query module is used to query whether the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree;

[0034] The module is configured to open the first slave IAVL tree based on the first root hash value if the first root hash value exists in the main IAVL tree.

[0035] The concatenation module is used to calculate the hash value of the key value in the key-value pair, and concatenate the contract address with the hash value to obtain a new key value;

[0036] An insertion module is used to combine the new key value with the value value in the key-value pair to form first data to be stored, and to insert the first data to be stored into the first IAVL tree.

[0037] This application also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0038] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0039] In this embodiment, transaction data from blockchain blocks is obtained; the transaction data is parsed to obtain the contract address and key-value pairs corresponding to the transaction data; the existence of the first root hash value of the first slave IAVL tree corresponding to the contract address is queried in the main IAVL tree; if the first root hash value exists in the main IAVL tree, the first slave IAVL tree is opened according to the first root hash value; the hash value of the key value in the key-value pair is calculated, and the contract address is concatenated with the hash value to obtain a new key value; the new key value and the value value in the key-value pair are combined to form the first data to be stored, and the first data to be stored is inserted into the first slave IAVL tree. By adopting the above transaction data storage scheme, transaction data corresponding to the same smart contract can be stored on an independent IAVL tree. Compared with the original method of storing transaction data corresponding to different smart contracts on the same IAVL tree, this transaction data storage scheme can reduce the probability of IAVL tree height imbalance and reduce the number of self-balancing triggers. The storage of transaction data corresponding to different smart contracts is maintained on an independent IAVL tree, which makes the storage overhead much lower than using a single IAVL tree to store transaction data corresponding to all smart contracts. This can effectively reduce the consumption of server computing and storage resources and improve the storage throughput of the blockchain network. Attached Figure Description

[0040] Figure 1 This is a schematic diagram illustrating the application environment of the transaction data storage method according to an embodiment of this application;

[0041] Figure 2 A flowchart of one embodiment of the transaction data storage method described in this application;

[0042] Figure 3 A flowchart illustrating another embodiment of the transaction data storage method described in this application;

[0043] Figure 4 This is a program block diagram of one embodiment of the transaction data storage device described in this application;

[0044] Figure 5 This is a schematic diagram of the hardware structure of a computer device for executing a transaction data storage method, as provided in an embodiment of this application. Detailed Implementation

[0045] The advantages of this application are further illustrated below with reference to the accompanying drawings and specific embodiments.

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

[0047] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0048] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0049] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0050] The following provides an exemplary application environment for this application. Figure 1 The illustration shows a schematic diagram of the application environment of the transaction data storage method according to an embodiment of this application.

[0051] See Figure 1 Blockchain 100 is a typical distributed collaborative system. This system includes multiple blockchain nodes 110. These multiple blockchain nodes 110 can jointly maintain a continuously growing distributed data record. The data in these records can be protected in terms of content and time sequence using cryptographic techniques, making it difficult for any party to tamper with, deny, or forge. Blockchain nodes 110 can be devices with computing capabilities, such as servers, server groups, blockchain chips, etc., where server groups can be centralized or distributed. In some implementations, the aforementioned servers can also be servers providing services to a cloud platform.

[0052] In a blockchain, data (such as transaction information, transaction execution results, etc.) can be encapsulated in the form of blocks. Blocks can be linked together through forward references to form a "chain," i.e., a blockchain. Typically, the first block in a blockchain is called the "genesis block" or "initial block," the block preceding the current block is called the "previous block," and the block following the current block is called the "successor block."

[0053] Typically, a block can include a block header and a block body. The block header contains basic information about the current block to ensure it is correctly entered into the blockchain. For example, the block header might record the block hash of the previous block. It might also record the block height, which identifies the block's position in the blockchain. In some implementations, the genesis block has a height of 0. The block body records transaction information, such as the number of transactions and transaction data.

[0054] Blockchains are generally classified into three types: public blockchains, private blockchains, and consortium blockchains. Furthermore, combinations of these types are possible, such as private blockchain + consortium blockchain, or consortium blockchain + public blockchain. The implementation methods provided in this disclosure can be implemented in suitable types of blockchains.

[0055] In a blockchain system, the validity of a record is determined through a consensus mechanism. This consensus mechanism can be understood as how the nodes responsible for recording transactions in the blockchain (or the ledger nodes) reach a consensus to determine the validity of a record.

[0056] Blockchain's consensus mechanism features "majority rule" and "equality for all." "Majority rule" doesn't solely refer to the number of nodes; it can also be computing power, shareholding, or other comparable computer characteristics. "Equality for all" means that when nodes meet certain conditions, all nodes have the right to propose a consensus result first, which can then be directly accepted by other nodes and potentially become the final consensus result. Taking Bitcoin as an example, it uses proof-of-work. Only by controlling more than 51% of the network's accounting nodes is it possible to forge a non-existent record. When a sufficient number of nodes join the blockchain, this becomes virtually impossible, thus eliminating the possibility of forgery.

[0057] The self-trust inherent in blockchain technology lies in the fact that users distributed across the blockchain do not need to trust the other party in a transaction, nor do they need to trust a centralized institution; they only need to trust the software system under the blockchain protocol to complete a transaction. This self-trust is predicated on the blockchain's consensus mechanism. In a market where there is no mutual trust, the necessary and sufficient condition for nodes to reach a consensus is that each node, driven by the pursuit of its own maximum benefit, will spontaneously and honestly adhere to the pre-defined rules of the protocol, verify the authenticity of each record, and ultimately record the verifiable records in the blockchain. In other words, if nodes have independent interests and compete with each other, it is virtually impossible for them to collude to deceive you. This is especially evident when nodes possess public credibility within the network. Blockchain technology uses a consensus-based mathematical algorithm to establish a "trust" network between machines, thereby creating new forms of credit through technological endorsement rather than centralized credit institutions.

[0058] The consensus mechanism of a blockchain can be one of the following: Proof of Work (PoW), Proof of Stake, Delegated Proof of Stake, Verification Pool, and Practical Byzantine Fault Tolerance (PBFT).

[0059] In blockchain systems, transactions are executed through smart contracts. A smart contract is a protocol or contract within the blockchain system that can be executed automatically, allowing for trusted transactions without a third party. These transactions are traceable and irreversible. A smart contract is a set of promises defined in digital form, including the protocols by which the contract participants can execute these promises. Alternatively, a smart contract can be understood as a program deployed on a computer system that can be executed automatically when its triggering conditions are met.

[0060] In the blockchain field, another important concept is the account. For blockchain networks that support smart contracts, blockchain accounts can generally be divided into the following two types:

[0061] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code; it can typically only be activated by an external account.

[0062] Externally owned account: This is an account directly controlled by the user, also known as a user account.

[0063] The design of external accounts and contract accounts is essentially a mapping from account addresses to account states. The state of an account is typically represented by a structure. When a transaction in a block is executed, the state of the account associated with that transaction in the blockchain usually changes.

[0064] In one example, the account structure typically includes fields such as Balance, Nonce, Codehash, and Storageroot. Among these:

[0065] The Balance field is used to maintain the current account balance.

[0066] The Nonce field is used to maintain the number of transactions for this account. It is a counter used to ensure that each transaction can be processed exactly once, effectively preventing replay attacks;

[0067] The Codehash field is used to maintain the contract code for this account. In practice, the Codehash field typically only maintains the hash value of the contract code.

[0068] The Storageroot field is used to maintain the storage content of this account. For contract accounts, a separate persistent storage space is typically allocated to store the contract data corresponding to that contract account. This separate storage space is usually referred to as the account storage for that contract account.

[0069] Contract account data is typically stored in key-value pairs, constructed into a logical tree structure. For example, a Merkle tree is a commonly used logical tree structure in the blockchain field for storing and maintaining blockchain data. A Merkle tree is a binary tree where the parent node stores the hash of its left and right child nodes, and the specific business data is stored in the leaf nodes.

[0070] The logical tree structure built based on the stored content of the contract account is often referred to as a Storage tree. The Storageroot field typically only maintains the hash value of the root node of this Storage tree. For external accounts, both the Codehash and Storageroot fields shown above have null values.

[0071] See Figure 2 This is a flowchart illustrating a transaction data storage method according to an embodiment of this application. It should be understood that the flowchart in this method embodiment is not intended to limit the order of execution steps. As can be seen from the figure, the transaction data storage method provided in this embodiment includes:

[0072] Step S21: Obtain transaction data from the blockchain blocks.

[0073] Specifically, when a user initiates N transactions for a smart contract (i.e., a contract account), the blockchain system will package the N transactions into a block of the blockchain system. Then, the transactions in the block will be processed through a consensus mechanism across the entire network. After the consensus is successful, the blockchain system will obtain all the transaction data from the block and then execute each of the obtained transaction data in sequence.

[0074] Step S21: Parse the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data.

[0075] Specifically, since each transaction data stored in a block is packaged into the block in the form of bytecode, when retrieving each transaction data from the block, in order to facilitate the subsequent storage of the transaction data into the IAVL tree, it is necessary to first parse the transaction data in bytecode form to obtain the contract address and key-value pair corresponding to the transaction data.

[0076] The contract address is a smart contract that maps an account address to its balance.

[0077] In this embodiment, when there are multiple transaction data in a block, the multiple transaction data can be parsed sequentially or in parallel. This embodiment does not impose any limitations.

[0078] In one exemplary embodiment, to improve the security of transaction data, the process further includes the following steps before parsing the transaction data:

[0079] The signature information of the sender of the transaction data is verified.

[0080] In this embodiment, the legitimacy of the transaction data can be determined by verifying the sender's signature information. If the sender's signature verification fails, it indicates that the transaction data is not legitimate and no further processing is required. Only when the sender's signature verification passes, indicating that the transaction data is legitimate, will further parsing of the transaction data proceed.

[0081] Step S22: Query whether the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree.

[0082] Specifically, the IAVL tree is the underlying storage structure used by the Cosmos framework, and is essentially a variant of Merkle tree + AVL tree.

[0083] Cosmos is a well-known blockchain development framework that allows developers to quickly deploy blockchain systems.

[0084] Merkle trees are the most commonly used underlying storage structure in blockchains, and the root hash can ensure that the data in the entire tree is immutable.

[0085] AVL trees are the first self-balancing binary search trees invented. In an AVL tree, the maximum difference in height between the two subtrees of any node is 1, so it is also called a height-balanced tree.

[0086] In this embodiment, the main IAVL tree is an IAVL tree used to store different contract addresses and the root hash values ​​of the corresponding subsidiary IAVL trees. The subsidiary IAVL trees are IAVL trees used to store transaction data belonging to the target contract address. For example, in a blockchain system with 5 contract addresses, 5 subsidiary IAVL trees need to be created to store the transaction data corresponding to these 5 contract addresses. That is, each subsidiary IAVL tree is used to store the transaction data corresponding to the contract address associated with that IAVL tree.

[0087] In one specific implementation, when querying whether the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree, it is possible to check whether the query result is empty. If the query result is not empty, it can be determined that the contract address does not belong to the new contract address. At this time, the returned query result can be used as the first root hash value of the first slave IAVL tree corresponding to the contract address.

[0088] Step S23: If the first root hash value exists in the main IAVL tree, then open the first slave IAVL tree according to the first root hash value.

[0089] Specifically, when the first root hash value exists in the main IAVL tree, the first secondary IAVL tree corresponding to the first root hash value can be found and opened based on the first root hash value, so that transaction data related to the contract address can be inserted into the first secondary IAVL tree.

[0090] Step S24: Calculate the hash value of the key value in the key-value pair, and concatenate the contract address with the hash value to obtain a new key value.

[0091] Specifically, when obtaining key-value pairs, the hash value of the key in the key-value pair is calculated. For example, the hash value obtained is 'a'.

[0092] In one exemplary implementation, the hash value of the key value in the key-value pair can be calculated using a preset hash algorithm.

[0093] The hash algorithm can be MD5, SHA-1, SHA-256, SHA-512, etc.

[0094] In this embodiment, the preset hash algorithm is preferably the SHA-256 algorithm. The SHA-256 algorithm is a sub-algorithm of SHA-2; it is a cryptographic hash function, simply put, it is a hash function. For a message of any length, SHA256 will produce a 256-bit hash value, called a message digest, which can be represented by a 64-bit hexadecimal string.

[0095] In this embodiment, after obtaining the hash value 'a', it is concatenated with the contract address 'addrA' to obtain a new key value, i.e., the new key value newKey = addrA + a or newKey = a + addrA. In other words, in this embodiment, the hash value 'a' in the concatenated newKey can be placed before or after the contract address; this is not limited in this embodiment.

[0096] Step S25: Combine the new key value with the value value in the key-value pair to form the first data to be stored, and insert the first data to be stored into the first IAVL tree.

[0097] Specifically, the new key value and the value value in the key-value pair can form the data to be stored, newKey-value.

[0098] When the first data to be stored, newKey-value, is formed, it can be inserted into the first IAVL tree to achieve persistent storage of the data.

[0099] In one exemplary implementation, after the first data to be stored is inserted into the first slave IAVL tree, the self-balance of the first slave IAVL tree can be checked. If the self-balance of the first slave IAVL tree is broken, a self-balancing action is triggered. If the self-balance of the first slave IAVL tree is not broken, a self-balancing action is not triggered.

[0100] This embodiment obtains transaction data from blockchain blocks; parses the transaction data to obtain the corresponding contract address and key-value pairs; queries the main IAVL tree to see if the first root hash value of the first slave IAVL tree corresponding to the contract address exists; if the first root hash value exists in the main IAVL tree, the first slave IAVL tree is opened based on the first root hash value; calculates the hash value of the key value in the key-value pair, and concatenates the contract address with the hash value to obtain a new key value; combines the new key value with the value value in the key-value pair to form the first data to be stored, and inserts the first data to be stored into the first slave IAVL tree. By adopting the above transaction data storage scheme, transaction data corresponding to the same smart contract can be stored on an independent IAVL tree. Compared with the original method of storing transaction data corresponding to different smart contracts on the same IAVL tree, this transaction data storage scheme can reduce the probability of IAVL tree height imbalance and reduce the number of self-balancing triggers. The storage of transaction data corresponding to different smart contracts is maintained on an independent IAVL tree, which makes the storage overhead much lower than using a single IAVL tree to store transaction data corresponding to all smart contracts. This can effectively reduce the consumption of server computing and storage resources and improve the storage throughput of the blockchain network.

[0101] In one exemplary embodiment, after the step of inserting the first data to be stored into the first IAVL tree, the method further includes: calculating the second root hash value of the first IAVL tree and updating the first root hash value stored in the main IAVL tree with the second root hash value; and calculating the third root hash value of the main IAVL tree.

[0102] Specifically, after storing the first data to be stored into the first slave IAVL tree, any change to any leaf node in the IAVL tree will be propagated to the parent node, ultimately causing a change in the root. Therefore, after storing the first data to be stored into the first slave IAVL tree, it is necessary to recalculate the root hash value of the first slave IAVL tree to obtain the second root hash value, and update the previous root hash value of the first slave IAVL tree with this second root hash value. Simultaneously, since the main IAVL tree also stores the first root hash value, to ensure the immutability of the data, it is also necessary to update the first root hash value stored in the main IAVL tree with the second root hash value. Furthermore, since changes in the data stored in the main IAVL tree will also cause changes in the root of the main IAVL tree, it is necessary to recalculate the root hash value of the main IAVL tree to obtain the third root hash value.

[0103] See Figure 3This is a flowchart illustrating a transaction data storage method according to another embodiment of this application. It is understood that the flowchart in this method embodiment is not intended to limit the order of execution steps. As can be seen from the figure, the transaction data storage method provided in this embodiment includes:

[0104] Step S30: Obtain transaction data from the blockchain blocks.

[0105] Step S31: Parse the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data.

[0106] Step S32: Query whether the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree.

[0107] Specifically, steps S30-S32 are the same as steps S20-S22 in the above embodiment, and will not be repeated in this embodiment.

[0108] Step S33: If the first root hash value does not exist in the main IAVL tree, then it is determined that the contract address belongs to a new contract address.

[0109] Specifically, when the query result is empty, it can be determined that the first hash value does not exist in the main IAVL tree, and at the same time, it can be determined that the contract address belongs to a new contract address.

[0110] Step S34: Create the second IAVL tree corresponding to the new contract address.

[0111] Specifically, when it is determined that the contract address belongs to a new contract address, in order to store the transaction data corresponding to the new contract address, the blockchain system will create a new IAVL tree, that is, it will create a second IAVL tree corresponding to the new contract address to store the transaction data corresponding to the new contract address.

[0112] Step S35: Calculate the hash value of the key value in the key-value pair, and concatenate the hash value with the new contract address to obtain the concatenated key value.

[0113] Specifically, when obtaining key-value pairs, the hash value of the key in the key-value pair is calculated. For example, the hash value obtained is b.

[0114] In one exemplary implementation, the hash value of the key value in the key-value pair can be calculated using a preset hash algorithm.

[0115] The hash algorithm can be MD5, SHA-1, SHA-256, SHA-512, etc.

[0116] In this embodiment, after obtaining the hash value b, it is concatenated with the contract address addrA to obtain the concatenated key value. That is, the concatenated key value = addrA + b or the concatenated key value = b + addrA. In other words, in this embodiment, the hash value b can be placed before or after the contract address in the concatenated key value, and there is no limitation in this embodiment.

[0117] Step S36: Combine the concatenated key value with the value in the key-value pair to form the second data to be stored, and insert the second data to be stored into the second IAVL tree.

[0118] Specifically, the concatenated key value and the value in the key-value pair can form the second data to be stored, NewKey-value.

[0119] When the second data to be stored, NewKey-value, is formed, it can be inserted into the second IAVL tree to achieve persistent storage of the data.

[0120] In one exemplary implementation, after the second data to be stored is inserted into the second IAVL tree, the self-balance of the second IAVL tree can be checked. If the self-balance of the second IAVL tree is broken, a self-balancing action is triggered. If the self-balance of the second IAVL tree is not broken, a self-balancing action is not triggered.

[0121] This embodiment obtains transaction data from blockchain blocks; parses the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data; queries the main IAVL tree to see if the first root hash value of the first slave IAVL tree corresponding to the contract address exists; if the first root hash value does not exist in the main IAVL tree, it is determined that the contract address belongs to a new contract address; creates a second slave IAVL tree corresponding to the new contract address; calculates the hash value of the key value in the key-value pair, and concatenates the new contract address with the hash value to obtain the concatenated key value; combines the concatenated key value with the value value in the key-value pair to form second data to be stored, and inserts the second data to be stored into the second slave IAVL tree. By adopting the above transaction data storage scheme, when there is no IAVL tree in the current blockchain system to store the transaction data corresponding to the contract address, a new IAVL tree can be created. This allows transaction data corresponding to the same smart contract to be stored on an independent IAVL tree. Compared with storing transaction data corresponding to different smart contracts on the same IAVL tree, this transaction data storage scheme can reduce the probability of IAVL tree height imbalance and reduce the number of self-balancing triggers. The storage of transaction data corresponding to different smart contracts is maintained on independent IAVL trees, making the storage overhead much lower than using a single IAVL tree to store the transaction data corresponding to all smart contracts. This can effectively reduce the consumption of server computing and storage resources and improve the storage throughput of the blockchain network.

[0122] In one exemplary embodiment, the method further includes: calculating the fourth root hash value of the second IAVL tree, and combining the new contract address and the fourth root hash value to form a third data to be stored, wherein the new contract address serves as the key value in the third data to be stored, and the fourth hash value serves as the value value in the third data to be stored; inserting the third data to be stored into the main IAVL tree; and calculating the fifth root hash value of the main IAVL tree.

[0123] Specifically, after storing the second data to be stored in the second slave IAVL tree, to ensure the immutability of the data, it is necessary to calculate the fourth root hash value of the second slave IAVL tree. Simultaneously, to facilitate the storage of the four hash values ​​into the main IAVL tree, the new contract address and the fourth hash value need to be combined into a key-value pair to form the third data to be stored. Once the third data to be stored is formed, it can be conveniently and quickly inserted into the main IAVL tree, achieving persistent storage of the third data. Furthermore, since changes in the data stored in the main IAVL tree will cause changes to the root of the main IAVL tree, to ensure the immutability of the data, it is necessary to recalculate the root hash value of the main IAVL tree to obtain the fifth root hash value.

[0124] See Figure 4 The diagram shown is a program block diagram of an embodiment of the transaction data storage device 40 of this application.

[0125] In this embodiment, the transaction data storage device 40 includes a series of computer program instructions stored in a memory. When these computer program instructions are executed by a processor, the imaging function of each embodiment of this application can be implemented. In some embodiments, based on the specific operations implemented by each part of the computer program instructions, the transaction data storage device 40 can be divided into one or more modules. Specifically, the modules that can be divided are as follows:

[0126] Module 41 is used to obtain transaction data from blocks in the blockchain;

[0127] Parsing module 42 is used to parse the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data;

[0128] Query module 43 is used to query whether the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree;

[0129] Open module 44 is used to open the first slave IAVL tree according to the first root hash value if the first root hash value exists in the main IAVL tree;

[0130] The splicing module 45 is used to calculate the hash value of the key value in the key-value pair, and splice the contract address with the hash value to obtain a new key value;

[0131] Insertion module 46 is used to combine the new key value with the value value in the key-value pair to form first data to be stored, and insert the first data to be stored into the first IAVL tree.

[0132] In one exemplary embodiment, the transaction data storage device 40 further includes an update module and a calculation module.

[0133] The update module is used to calculate the second root hash value of the first IAVL tree and update the first root hash value stored in the main IAVL tree with the second hash value.

[0134] The calculation module is used to calculate the third root hash value of the main IAVL tree.

[0135] In one exemplary embodiment, the transaction data storage device 40 further includes a determination module and a creation module.

[0136] The determination module is used to determine that the contract address belongs to a new contract address if the first root hash value does not exist in the main IAVL tree.

[0137] The creation module is used to create a second IAVL tree corresponding to the new contract address.

[0138] The splicing module 45 is also used to calculate the hash value of the key value in the key-value pair, and to splice the new contract address with the hash value to obtain the spliced ​​key value.

[0139] The insertion module 46 is further configured to combine the concatenated key value with the value in the key-value pair to form a second data to be stored, and insert the second data to be stored into the second IAVL tree.

[0140] In one exemplary embodiment, the calculation module is further configured to calculate the fourth root hash value of the second IAVL tree, and to combine the new contract address and the fourth root hash value into a third set of data to be stored, wherein the new contract address serves as the key value in the third set of data to be stored, and the fourth hash value serves as the value value in the third set of data to be stored.

[0141] The insertion module 46 is also used to insert the third data to be stored into the main IAVL tree.

[0142] The calculation module is also used to calculate the fifth root hash value of the main IAVL tree.

[0143] In one exemplary embodiment, the splicing module 45 is further configured to calculate the hash value of the key value in the key-value pair using a preset hash algorithm.

[0144] In one exemplary embodiment, the transaction data storage device further includes a verification module.

[0145] The verification module is used to verify the signature information of the sender of the transaction data.

[0146] In one exemplary embodiment, the verification module is further configured to verify whether the self-balance of the first IAVL tree has been broken. If the self-balance of the first IAVL tree is broken, a self-balancing action is triggered.

[0147] This embodiment obtains transaction data from blockchain blocks; parses the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data; queries whether the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree; if the first root hash value exists in the main IAVL tree, the first slave IAVL tree is opened according to the first root hash value; calculates the hash value of the key value in the key-value pair, and concatenates the contract address with the hash value to obtain a new key value; combines the new key value with the value value in the key-value pair to form the first data to be stored, and inserts the first data to be stored into the first slave IAVL tree. By adopting the above transaction data storage scheme, transaction data corresponding to the same smart contract can be stored on an independent IAVL tree. Compared with the original method of storing transaction data corresponding to different smart contracts on the same IAVL tree, this transaction data storage scheme can reduce the probability of IAVL tree height imbalance and reduce the number of self-balancing triggers. The storage of transaction data corresponding to different smart contracts is maintained on an independent IAVL tree, which makes the storage overhead much lower than using a single IAVL tree to store transaction data corresponding to all smart contracts. This can effectively reduce the consumption of server computing and storage resources and improve the storage throughput of the blockchain network.

[0148] Figure 5 This illustration schematically shows a hardware architecture diagram of a computer device 5 suitable for implementing a transaction data storage method according to an embodiment of this application. In this embodiment, the computer device 5 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. For example, it may be a tablet computer, laptop computer, desktop computer, rack server, blade server, tower server, or cabinet server (including independent servers or server clusters composed of multiple servers), etc. Figure 5 As shown, computer device 5 includes, but is not limited to: a memory 120, a processor 121, and a network interface 122 that can communicate with each other via a system bus. Wherein:

[0149] The memory 120 includes at least one type of computer-readable storage medium, which can be volatile or non-volatile. Specifically, the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 120 may be an internal storage module of the computer device 5, such as the hard disk or memory of the computer device 5. In other embodiments, the memory 120 may also be an external storage device of the computer device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 5. Of course, the memory 120 may also include both the internal storage module and the external storage device of the computer device 5. In this embodiment, the memory 120 is typically used to store the operating system and various application software installed on the computer device 5, such as program code for transaction data storage methods. Furthermore, the memory 120 can also be used to temporarily store various types of data that have already been output or will be output.

[0150] In some embodiments, processor 121 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other imaging chip. This processor 121 is typically used to control the overall operation of the computer device 5, such as performing control and processing related to data interaction or communication with the computer device 5. In this embodiment, processor 121 is used to run program code stored in memory 120 or process data.

[0151] Network interface 122 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 5 and other computer devices. For example, network interface 122 is used to connect computer device 5 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 5 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0152] It should be pointed out that, Figure 5 Only computer devices with components 120 to 122 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0153] In this embodiment, the transaction data storage method stored in memory 120 can be divided into one or more program modules and executed by one or more processors (processor 121 in this embodiment) to complete this application.

[0154] This application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the transaction data storage method in the embodiment.

[0155] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium can be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Of course, the computer-readable storage medium can also include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the transaction data storage method in the embodiment. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0156] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across at least two network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of this application. Those skilled in the art can understand and implement this without any creative effort.

[0157] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0158] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for storing transaction data, characterized in that, include: Retrieve transaction data from blocks in the blockchain; The transaction data is parsed to obtain the contract address and key-value pairs corresponding to the transaction data; Check if the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree; If the first root hash value exists in the main IAVL tree, then the first slave IAVL tree is opened according to the first root hash value; Calculate the hash value of the key in the key-value pair, and concatenate the contract address with the hash value to obtain a new key value; The new key value and the value in the key-value pair are combined to form the first data to be stored, and the first data to be stored is inserted into the first IAVL tree; The main IAVL tree is an IAVL tree used to store different contract addresses and the root hash values ​​of the corresponding IAVL trees for different contract addresses; the secondary IAVL trees are IAVL trees used to store transaction data for the corresponding contract addresses.

2. The transaction data storage method according to claim 1, characterized in that, After the step of inserting the first data to be stored into the first IAVL tree, the method further includes: Calculate the second root hash value of the first IAVL tree, and update the first root hash value stored in the main IAVL tree with the second hash value; Calculate the third root hash value of the main IAVL tree.

3. The transaction data storage method according to claim 2, characterized in that, The method further includes: If the first hash value does not exist in the main IAVL tree, then the contract address is determined to belong to a new contract address; Create a second IAVL tree corresponding to the new contract address; Calculate the hash value of the key value in the key-value pair, and concatenate the new contract address with the hash value to obtain the concatenated key value; The concatenated key value and the value in the key-value pair are combined to form the second data to be stored, and the second data to be stored is inserted into the second IAVL tree.

4. The transaction data storage method according to claim 3, characterized in that, The method further includes: Calculate the fourth root hash value of the second IAVL tree, and combine the new contract address and the fourth root hash value to form the third data to be stored, wherein the new contract address is used as the key value in the third data to be stored, and the fourth hash value is used as the value value in the third data to be stored. Insert the third data to be stored into the main IAVL tree; Calculate the fifth root hash value of the main IAVL tree.

5. The transaction data storage method according to any one of claims 1 to 4, characterized in that, The calculation of the hash value of the key value in the key-value pair includes: The hash value of the key in the key-value pair is calculated using a preset hash algorithm.

6. The transaction data storage method according to claim 1, characterized in that, Before parsing the transaction data, the process also includes: The signature information of the sender of the transaction data is verified.

7. The transaction data storage method according to claim 1, characterized in that, The method further includes: The first IAVL tree checks whether its own balance has been broken. If the first IAVL tree's own balance has been broken, a self-balancing action is triggered.

8. A transaction data storage device, characterized in that, include: The acquisition module is used to acquire transaction data from blocks in the blockchain; The parsing module is used to parse the transaction data to obtain the contract address and key-value pairs corresponding to the transaction data; The query module is used to query whether the first root hash value of the first slave IAVL tree corresponding to the contract address exists in the main IAVL tree; The module is configured to open the first slave IAVL tree based on the first root hash value if the first root hash value exists in the main IAVL tree. The concatenation module is used to calculate the hash value of the key value in the key-value pair, and concatenate the contract address with the hash value to obtain a new key value; An insertion module is used to combine the new key value with the value value in the key-value pair to form first data to be stored, and to insert the first data to be stored into the first IAVL tree; The main IAVL tree is an IAVL tree used to store different contract addresses and the root hash values ​​of the corresponding IAVL trees for different contract addresses; the secondary IAVL trees are IAVL trees used to store transaction data for the corresponding contract addresses.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product comprising a computer program, characterized in that: When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images