Method and device for updating account state in block chain

Abstract

The method for updating the account state in the block chain comprises the following steps: in response to execution completion of a first transaction sent by a first account, obtaining a Merck tree corresponding to the first account, and adding a first leaf node corresponding to the first transaction in the Merck tree, the first leaf node at least comprises a serial number value nonce and a transaction hash value of the first transaction. And based on the first leaf node, updating the Merk tree to obtain an updated root hash value. And storing the root hash value into the state of the first account.

Description

Technical Field

[0001] The embodiments of this specification belong to the technical field of blockchain, and particularly relate to a method and device for updating account status in a blockchain. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. In a blockchain system, data blocks are combined into a chained data structure in a sequential connection manner according to the time sequence, and a distributed ledger that is immutable and unforgeable is guaranteed by cryptographic means. Due to the characteristics of blockchain such as decentralization, immutability of information, and autonomy, blockchain has received more and more attention and applications.

[0003] In a new generation of blockchain, such as Ethereum, the concept of an account is added. Correspondingly, users can create accounts through the blockchain platform. In this scenario, an account can include an external account and a contract account. An external account is an account created by a user through a private key, which is a mapping of a real-world account, and the user who owns the private key of the account can control the account. A contract account is an account containing contract code, which is created by an external account or a contract. When the contract is created, it is automatically assigned an account address for storing the contract code and the data generated during the contract deployment or execution.

[0004] In a blockchain network, any transaction sent by an account will be encoded and stored in the account status, and then persisted in the database. When the number of transactions of an account is too large, storing or reading transactions will cause serious read amplification and write amplification, and the performance of random queries is low.

[0005] Therefore, a solution is needed to more efficiently update the transaction data in the account status to improve the overall performance of the blockchain network. Summary of the Invention

[0006] The purpose of the present invention is to provide a method for updating account status in a blockchain, including:

[0007] The first aspect of this specification provides a method for updating account status in a blockchain, including:

[0008] In response to the completion of the execution of a first transaction sent by a first account, obtain the Merkle tree corresponding to the first account, and add a first leaf node corresponding to the first transaction to the Merkle tree. The first leaf node includes at least the sequence number value nonce and the transaction hash value of the first transaction.

[0009] Based on the first leaf node, update the Merkle tree to obtain an updated root hash value.

[0010] Store the root hash value into the state of the first account.

[0011] According to one implementation, multiple leaf nodes of the Merkle tree are arranged in ascending order of the sequence numbers of their corresponding transactions from left to right in the tree; adding the first leaf node corresponding to the first transaction to the Merkle tree includes:

[0012] Add the first leaf node at the rightmost side of the leaf node layer of the Merkle tree.

[0013] According to one implementation, the first leaf node further includes the block number of the block to which the first transaction belongs and the transaction index number in the block.

[0014] According to one implementation, the state of the first account includes: a transaction count field for indicating the number of sent transactions; the method further includes:

[0015] Store the largest sequence number value among the leaf nodes of the Merkle tree into the transaction count field.

[0016] According to one implementation, the Merkle tree is an N-ary Merkle tree structure; in response to the addition of the first leaf node, updating the Merkle tree includes i rounds of layer-by-layer updates starting from the 0th layer of the Merkle tree, where the 0th layer is the leaf node layer and the ith layer is the root node layer, and any round of update includes:

[0017] Perform a first update on the first parent node of the current processing layer, where the child nodes of the first parent node include: updated nodes, and / or, newly added nodes; the newly added nodes include: M newly added placeholder child nodes, so that the number of child nodes of the first parent node can be divisible by N; the first update includes updating the hash value of the node according to the hash values of all child nodes included in the node.

[0018] Take the next layer of the current processing layer as the processing layer for the next round of update.

[0019] The second aspect of this specification provides a method for querying transactions in a blockchain, including:

[0020] Receive a query request for a target transaction.

[0021] Obtain the Merkle tree corresponding to the sending account of the target transaction, and the Merkle tree is updated by the method according to any one of claims 1-5.

[0022] Determine the target leaf node corresponding to the target transaction in the Merkle tree according to the sequence number nonce of the target transaction.

[0023] According to one implementation, the method further includes:

[0024] In the Merkle tree, extract the hash values of each associated node on the Merkle path corresponding to the target leaf node.

[0025] Perform a simple payment verification on the target transaction according to the hash value of the target transaction, the hash values of the associated nodes, and the hash value of the Merkle root node.

[0026] The third aspect of this specification provides a device for updating an account state in a blockchain, including:

[0027] An adding module, configured to, in response to the completion of the execution of a first transaction sent by a first account, obtain the Merkle tree corresponding to the first account, and add a first leaf node corresponding to the first transaction in the Merkle tree, where the first leaf node at least includes the sequence number value nonce and the transaction hash value of the first transaction.

[0028] An updating module, configured to update the Merkle tree based on the first leaf node to obtain an updated root hash value.

[0029] A storage module, configured to store the root hash value in the state of the first account.

[0030] The fourth aspect of this specification provides a device for querying transactions in a blockchain, including:

[0031] A receiving module, configured to receive a query request for a target transaction.

[0032] An obtaining module, configured to obtain the Merkle tree corresponding to the account that sent the target transaction, where the Merkle tree is updated by the device of claim 8.

[0033] A determining module, configured to determine the target leaf node corresponding to the target transaction in the Merkle tree according to the sequence number value nonce of the target transaction.

[0034] The fifth aspect of this specification provides a computing device, including a memory and a processor, where an executable code is stored in the memory, and when the processor executes the executable code, the method described in any one of the first aspect and the second aspect is implemented.

[0035] According to the methods and devices provided in the embodiments of this specification, after the execution of a transaction sent by an account is completed, a leaf node corresponding to this transaction is added to the Merkle tree, and the updated Merkle root node is stored in the state of this account. Thus, the Merkle tree can be used to manage the transactions of the account, more efficiently process the generation and query of transaction data, and further improve the system performance of the entire blockchain network. Description of the Drawings

[0036] To more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0037] Figure 1 Shows the blockchain architecture diagram in an embodiment;

[0038] Figure 2 Shows the organization method of an exemplary block structure and account status in the blockchain;

[0039] Figure 3 Shows an account status data organization structure disclosed in the embodiments of this specification;

[0040] Figure 4 Is a flowchart of a method for updating an account status in the blockchain provided according to the embodiments of this specification;

[0041] Figure 5 Is a flowchart of a method for querying transactions in the blockchain provided according to the embodiments of this specification;

[0042] Figure 6 Is a schematic diagram of a device for updating an account status in the blockchain provided according to the embodiments of this specification;

[0043] Figure 7 Is a schematic diagram of a device for querying transactions in the blockchain provided according to the embodiments of this specification. Specific embodiments

[0044] In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0045] Figure 1 Shows the blockchain architecture diagram in an embodiment. In Figure 1 In the shown blockchain architecture diagram, the blockchain includes N nodes, Figure 1Nodes 1 to 8 are schematically shown. The connections between the nodes schematically represent P2P (Peer to Peer) connections, which can be, for example, TCP connections, etc., for transmitting data between nodes. The full ledger can be stored on these nodes, that is, the states of all blocks and all accounts are stored. Among them, each node in the blockchain can generate the same state in the blockchain by executing the same transactions, and each node in the blockchain can store the same state database.

[0046] Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. A transaction usually includes at least a sending field (From), a receiving field (To), and a data field (Data). For example, in the case where the transaction is a transfer transaction, the From field represents the account address that sends the transaction (i.e., initiates the transfer task to another account), the To field represents the account address that receives the transaction (i.e., receives the transfer), and the transfer amount can be included in the Data field.

[0047] The blockchain can also provide the function of smart contracts. Smart contracts on the blockchain are a piece of code that can be triggered and executed by transactions on the blockchain system, and smart contracts are defined in the form of code. Invoking a smart contract in the blockchain is actually initiating a transaction pointing to the smart contract address, enabling each node in the blockchain to run the smart contract code distributively.

[0048] In various blockchain networks that introduce smart contracts, such as Ethereum, accounts usually can include two types:

[0049] Contract Account: Stores the executed smart contract code and the values of the states in the smart contract code, and usually can only be activated by being called by an external account.

[0050] Externally Owned Account: The user's account, such as the account of an asset token owner.

[0051] The design of external accounts and contract accounts is actually a mapping from account addresses to account states. The state of an account usually includes fields such as nonce, balance, storageRoot, codeHash, etc. Nonce and balance exist in both external accounts and contract accounts; the codeHash and storageRoot attributes are generally only valid for contract accounts.

[0052] nonce: A counter. For an external account, this number can represent the number of transactions sent from the account address; for a contract account, it can be the number of contracts created by the account.

[0053] balance: The quantity of asset tokens owned by the account address.

[0054] storageRoot: The hash of the root node of an MPT (Merkle Patricia Trie), which organizes the storage of the state variables of the contract account.

[0055] codeHash: The hash value of the smart contract code. For a contract account, it is the hash value of the smart contract; for an external account, since it does not include a smart contract, the codeHash field can generally be an empty string / a string of all zeros.

[0056] Figure 2 Shows an exemplary block structure and the organization method of account states in the blockchain.

[0057] Referring to the accompanying drawings, the block header of block N contains multiple important fields. For example, the previous block hash (shown as the parent hash in the figure) previous_Hash, timestamp Timestamp, state root hash State_Root, transaction root hash Transaction_Root, receipt root hash Receipt_Root, etc. Among them, the parent hash in the block header of the next block (shown as block N + 1 in the accompanying drawings) points to the previous block (i.e., block N). In this way, the blocks on the blockchain are locked one by one through the block headers. In addition, State_Root, Transaction_Root, and Receipt_Root lock the state set, transaction set, and receipt set respectively, and these sets organize the account states, transactions, and receipts in the form of trees. Generally, they can be the same tree structure or different tree structures. For example, in Ethereum, the same MPT structure is adopted. The block also contains a transaction list for recording all transaction information included in the block. Generally speaking, the transaction list is saved in the block body of the block.

[0058] The state root hash, State_Root, is the hash value of the root of the Merkle Patricia Trie (MPT) formed by the states of all accounts in the current block. That is, what points to State_Root is a state trie in the form of an MPT. The root node of this MPT is generally an extension node or a branch node, and what is stored in State_Root is generally the hash value of this root node. The root node can be connected to one or more layers of extension nodes and branch nodes below. These multi-layer tree nodes can be collectively referred to as internal nodes. Concatenating in order a part of the values in each node from the root node of the MPT to the leaf nodes can form an account address and serve as the key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. This key can also be a part of the result after hashing the address using sha3 (for example, using the sha3 algorithm for the hashing algorithm), and the value it stores can be RLP(Account), that is, the RLP (Recursive Length Prefix) encoding of the account information. The account information is a quadruple composed of [nonce, balance, storageRoot, codeHash].

[0059] As mentioned above, for an external account, generally there are only two items, nonce and balance, while the storageRoot and codeHash fields default to storing an empty string / all-zero string. That is to say, an external account does not store a contract nor the state variables generated after the contract is executed. A contract account generally includes Nonce, Balance, Storage root, and CodeHash. Among them, Nonce is the transaction counter of this contract account; Balance is the account balance; Storage root corresponds to another MPT, through which the information related to the contract state can be linked; CodeHash is the hash value of the contract code. Whether it is an external account or a contract account, their account information is generally located in a separate leaf node. From the Extension Node / Branch Node of the root node to the Leaf Node of each account, there may be several branch nodes and extension nodes in between.

[0060] In some related technologies, the account information may also include the summary information of each transaction sent by the account. Typically, the transaction summary information may include the transaction count nonce of the transaction, the block number (BlockNumber) of the block to which the transaction belongs, and the index number (Index) corresponding to the transaction in the transaction list of the block. After each historical transaction sent by the account is extracted as transaction summary information, it is RLP encoded and stored in the account state. This storage method can simplify the quick verification of a single transaction by directly embedding structured data. However, as the number of account transactions increases, the data scale of the transaction summary information stored in the account state grows linearly, and each read and write of the transaction summary information involves a complete RLP encoding and decoding process, resulting in increasingly serious read amplification and write amplification problems.

[0061] The occurrence of the above read amplification and write amplification problems is also related to the database structure adopted by the blockchain system. In the blockchain system, most databases adopt a NoSQL Key-Value DB (DataBase; Key-Value DB is also simply referred to as KVDB) with an LSM (Log-Structured Merge-Tree) type structure, and finally save the data on the disk. Specifically, the database is, for example, levelDB of Ethereum and RocksDB of Libra, and both of these KVDBs are based on the LSM storage engine.

[0062] The LSM storage engine is a hierarchical, ordered, disk-oriented storage engine. It draws on the feature of Log that data is continuously appended (instead of modified). Its core idea is to make full use of the fact that disk bulk sequential writes are far more efficient than random writes, sacrificing some read efficiency in exchange for maximizing write operation efficiency. Generally speaking, the way to maximize the use of disk characteristics is to read or write a fixed-size block of data at once and minimize random addressing operations as much as possible. The design idea of LSM is based on this disk characteristic and assumes that the memory is sufficient, so there is no need to write data to the disk every time there is an update. Instead, the latest data is first resident in the memory, and after the data volume accumulates enough, the data in the memory is merged with the data on the disk using merge sort and then bulk appended to the disk. Specifically, the latest data can be stored in the MemTable in the memory. The MemTable can provide concurrent read and write operations, and there can be multiple MemTables in the memory. When the data volume in the MemTable reaches a certain threshold, for example, when it reaches 256MB, the data in the MemTable can be written (flushed) to the disk. To avoid the write operation of the MemTable blocking the flush, this MemTable can be converted into an immutable Immutable Memtable, that is, the Immutable Memtable is set to read-only and a new MemTable is generated to receive newly incoming data. This new MemTable can provide concurrent read and write operations. Then, the storage engine writes the data in the ImmutableMemTable to the disk. In the disk, KVDB stores data in multiple levels of SST (Sorted StringTable, SSTable) files.

[0063] The SST can include multiple layers, such as 3 layers, 4 layers, 5 layers, 6 layers, 7 layers or more. Generally, the total capacity of the upper layer of the SST is significantly smaller than that of the lower layer. As an example, for an SST with a total of 3 layers, the total capacity of the SST at level 0 is 1GB, the total capacity of the SST at level 1 is 10GB, and the total capacity of the SST at level 2 is 100GB. Assuming that the capacity of the MemTable is 256MB, after the latest data corresponding to one or more blocks is written into the MemTable, the space occupied by the MemTable may reach 256MB. Subsequently, this MemTable is converted into an Immutable MemTable, and the data in the Immutable MemTable can be written (flushed, referring to the operation of writing data in memory to disk) to the disk. Specifically, the data in the MemTable can be flushed to the SST at Level 0 on the disk. On the other hand, as mentioned above, a new MemTable is generated to receive newly incoming data and provide concurrent read and write operations.

[0064] Furthermore, when the storage capacity of the SST at Level 0 reaches or approaches the upper limit, the data at Level 0 is written into Level 1 through a process called "compaction". During this compaction process, the k-v (key-value pairs) in each SST within Level 0 and some or all of the k-v in the SSTs within Level 1 can be first transferred into memory, sorted in memory, and then written into the SST at Level 1. Since sorting is performed during the compaction process, within the SST at Level 1, there is an order relationship in the values of k, and there is a size relationship in the ranges of k among multiple SSTs at Level 1. In other words, within each SST at Level 1, the k-v is in accordance with <k1-v1> <k2-v2> <k3-v3> ... <kn-vn>arranged in the manner that k1 < k2 < k3 <... < kn, and k1, k2, k3,... kn are not necessarily consecutive. Moreover, overall, for two adjacent SSTs, the minimum value of k in the left SST < the maximum value of k in the left SST < the minimum value of k in the right SST < the maximum value of k in the right SST.

[0065] Similarly, when the storage capacity of Level 1 reaches the upper limit, the data in Level 1 is written into Level 2 through the compaction process. Similarly, during this compaction process, the key-value pairs (k-v) in each SST in Level 1 and some or all of the k-v in the SSTs in Level 2 can be first transferred to the memory, sorted in the memory, and then written into the SSTs in Level 2. Similarly, if there is a Level 3 below Level 2, when the storage capacity of Level 2 reaches the upper limit, the data in Level 2 is written into Level 3 through the compaction process. Similarly, during this compaction process, the k-v in each SST in Level 2 and some or all of the k-v in the SSTs in Level 3 can be first transferred to the memory, sorted in the memory, and then written into the SSTs in Level 3, and so on.

[0066] In this way, overall, the data stored in the upper-layer SSTs is newer than that in the lower layer. The latest data is stored in the memory, the second latest data is stored in Level 0,... the oldest data is stored in the SSTs within the bottommost Level.

[0067] From the above description, it can be known that during the process of updating the account status after a certain transaction is executed, several key steps are involved, including decoding the RLP encoding of the transaction summary information in the account status, updating the transaction summary information, RLP encoding, and storing it in the database. When the account frequently sends transactions / there are too many transactions, the data scale of the transaction summary information will expand rapidly. Each time the account status is updated (for example, a new transaction is added), the transaction summary information of this account needs to be completely decoded, updated, encoded, and stored. In the query scenario, even if only the summary information of a certain transaction needs to be retrieved (which may be only a few dozen bytes of information fragments in the complete transaction summary information), the complete transaction summary information has to be decoded and loaded.

[0068] This process not only involves frequent RLP encoding and decoding operations, but also generates frequent database reads and writes. The database read process involves multi-level lookups of data, including the in-memory MemTable and various levels of SST files on disk; while the database write process requires RLP encoding of the reconstructed transaction summary information in the account state and persists it through the in-memory MemTable and various levels of SST files on disk, thus resulting in the problems of read amplification and write amplification.

[0069] After research, the inventors found that the above problems of read amplification and write amplification can be avoided by specially designing the data organization form of the account state. The following will briefly elaborate on the ideological framework of this technical discovery.

[0070] Continue to refer to the appendix Figure 2 In the state tree corresponding to the state root included in the block header, there are state data of each account (shown as "account" in the attached figure). The inventors found that in some related technologies, there are significant defects in the design of directly embedding the summary information of each transaction sent by the account in the form of RLP encoding into the account state. Whenever a new transaction is executed by the account, it is necessary to perform a full RLP encoding update on the transaction summary information in the account state, which not only causes frequent overwriting of the account state (write amplification) when writing transactions, but also requires complete decoding of the RLP encoding when querying the historical transactions of the account to retrieve in the complete transaction summary information (read amplification).

[0071] To solve the above technical problems, the inventors designed a new data organization form for account state, which can decouple the transaction summary information of the account from the account state, store it in an independent Merkle tree outside the account state, and associate the Merkle tree with the account state, so as to realize the storage and fast query of transaction summaries under the condition that the size of the account state data remains basically unchanged.

[0072] Figure 3 Shows an account state data organizational structure disclosed in an embodiment of this specification. It can be known that the attached figure shows a schematic diagram of the account state data structure designed to illustrate the embodiments of the present invention, and the data elements shown are fields and attributes used in the embodiments, but do not represent a limitation on the composition of the account state data. In actual applications, other data fields can be added to the account state according to business requirements.

[0073] Refer to the appendix Figure 3 , in the account status, the inventor designed a field for storing the Merkle root node hash value (shown as "Merkle root hash" in the attached figure), which stores the root hash value of the Merkle tree formed by the transactions sent by the current account. The root node of this Merkle tree can be connected to one or more layers of extension nodes and branch nodes below. These multi-layer tree nodes can be collectively referred to as internal nodes. The nodes at the bottom layer of the Merkle tree are leaf nodes. From the extension nodes and branch nodes of the root node to the leaf nodes, there may be several branch nodes and extension nodes in between. For the simplicity of the attached figure, in the attached Figure 3 figure, a three-layer Merkle tree is used as an example to elaborate on the data structure of the account status.

[0074] In the leaf nodes of the Merkle tree, each transaction sent by the account is stored, and its content can at least include the sequence number value nonce and transaction hash value of the transaction. Thus, each transaction sent by the current account can be maintained in the account status in the form of a Merkle tree. Through this organizational structure, the transaction hashes of each transaction in the account are organized in an orderly manner, forming an immutable transaction record chain, which can not only ensure the integrity and security of the transaction hash data, but also allow for quick verification of the existence and order of the transactions.

[0075] Next, in combination with the attached figure and embodiments, a method for updating the account status in a blockchain will be elaborated first, and then based on the updated account status, a method for querying transactions in a blockchain will be elaborated.

[0076] Following the above technical concept, in Figure 4 figure shows a method flow for updating the account status in a blockchain provided according to an embodiment of this specification. It can be understood that this method can be implemented by any device, equipment, platform, or device cluster with computing and processing capabilities. Refer to Figure 4 , the method at least includes the following steps: S401: In response to the completion of the execution of the first transaction sent by the first account, obtain the Merkle tree corresponding to the first account, and add a first leaf node corresponding to the first transaction to the Merkle tree. The first leaf node at least includes the sequence number value nonce and transaction hash value of the first transaction. S403: Based on the first leaf node, update the Merkle tree to obtain an updated root hash value. S405: Store the root hash value in the status of the first account.

[0077] Specifically, in step S401, in response to the completion of the execution of the first transaction sent by the first account, obtain the Merkle tree corresponding to the first account, and add a first leaf node corresponding to the first transaction to the Merkle tree. The first leaf node includes at least the sequence number value nonce and the transaction hash value of the first transaction.

[0078] In a blockchain system, whenever a transaction is executed, the account state needs to be updated to reflect the result of the transaction. In this step, in response to the completion of the execution of the first transaction sent by the first account, it means that the first transaction has gone through consensus and transaction processing, and its transaction result (e.g., transfer of asset tokens, invocation of smart contracts, etc.) has been applied to the state of the blockchain.

[0079] Obtain the Merkle tree corresponding to the first account (i.e., the sender of the first transaction). As mentioned before, in this embodiment, a Merkle tree can be associated with each account state, and this Merkle tree is used to store the summary information of each transaction / transaction related to the account, such as each transaction sent by the account. The root hash value of the Merkle tree is stored in the account state of the first account as a compact representation of the transaction history of the first account.

[0080] In the obtained Merkle tree, add a first leaf node corresponding to the first transaction. This leaf node is composed of the relevant information of the first transaction and includes at least:

[0081] Sequence number value nonce of the transaction: An identification variable value used to ensure the uniqueness of the transaction order, which usually increments with each transaction sent by the account.

[0082] Transaction hash value: Usually obtained through hash calculation based on the transaction content and is a unique identifier used to identify the transaction.

[0083] The data composition of the above leaf node is not a specific limitation. The transaction information fields that can be included in the leaf node are diverse and can be defined according to specific business scenarios and requirements. According to one implementation, the first leaf node may further include the block number of the block to which the first transaction belongs and the transaction index number in the block.

[0084] Introducing the block number and transaction index number corresponding to the first transaction into the leaf nodes of the Merkle tree can further enhance the traceability and query efficiency of transaction data in the blockchain system. Specifically, by storing the block number of the block to which the first transaction belongs and the index position of the first transaction within that block in the leaf nodes, a direct association between the first transaction and the global state of the blockchain can be quickly established. That is, the block number points to the block height at which the first transaction was officially packaged, while the transaction index number precisely identifies the specific position of the first transaction in the transaction list of the block body. This design in this implementation enables the Merkle tree associated with the account state to not only ensure the transaction order and uniqueness through the transaction sequence number value nonce and the transaction hash value, but also directly associate with the original transaction data on the chain through the block number and the transaction index number, without relying on an external index table or a global traversal of the transaction list. In addition, this data structure of the leaf nodes can also provide more abundant context information to assist in querying in the scenario of tracing the historical transactions of a specific account. For example, transaction records within a certain time period can be quickly filtered based on the block number in the leaf nodes.

[0085] In one implementation, based on the transaction sequence number values contained in the leaf nodes, the respective leaf nodes of the Merkle tree can be organized in a specific order to form an ordered chain of transaction records. That is, the multiple leaf nodes of the Merkle tree can be arranged from left to right in the tree from smallest to largest according to the sequence number values of their corresponding transactions. When adding the first leaf node corresponding to the first transaction to the Merkle tree, the first leaf node can be added to the far right of the leaf node layer of the Merkle tree. This design utilizes the monotonically increasing property of the transaction sequence number value nonce (for a single account), and always adds the leaf node corresponding to the latest transaction sent by the account to the far right of the leaf node layer of the Merkle tree, causing the respective leaf nodes of the Merkle tree to be arranged in the order of increasing transaction sequence number values from left to right, without the need to readjust the positions of the existing leaf nodes. The ordered leaf nodes formed in this way not only achieve higher processing efficiency during addition, but also enable faster queries in the reading scenario. The reading operations related to the leaf nodes will be elaborated in detail below.

[0086] After adding the first leaf node to the Merkle tree, in step S403, update the Merkle tree based on the first leaf node to obtain an updated root hash value.

[0087] In this step, according to the first leaf node added to the Merkle tree, the hash values from the leaf node to the root node in the Merkle tree are recalculated to complete the update of the entire Merkle tree structure. Specifically, after adding a new leaf node (the first leaf node), starting from this leaf node, the hash values of all relevant intermediate nodes such as its parent node, grandparent node, etc. are updated layer by layer upward in the Merkle tree until a new root hash value is finally calculated. This update process ensures the integrity and consistency of the Merkle tree, making the root hash value of the Merkle tree accurately reflect the existence of all transactions of this account.

[0088] Generally speaking, the Merkle tree is a binary Merkle tree structure, and in some embodiments, according to the specific requirements of the data organization mode or storage efficiency for the business scenario, the Merkle tree can be defined as an N-ary Merkle tree structure. In this scenario, in response to the addition of the first leaf node, updating the first transaction tree includes i rounds of layer-by-layer updates starting from the 0th layer of the Merkle tree. The 0th layer is the leaf node layer, and the ith layer is the root node layer. Any round of update includes:

[0089] Perform a first update on the first parent node of the current processing layer. The children nodes of the first parent node include: updated nodes, and / or, newly added nodes; the newly added nodes include: M newly added placeholder child nodes, so that the number of children nodes of the first parent node can be divisible by N; the first update includes updating the hash value of this node according to the hash values of all the children nodes included in the node. Take the next layer of the current processing layer as the processing layer for the next round of update.

[0090] The introduction of the N-ary Merkle tree structure can meet the optimization requirements for data organization efficiency in high-concurrency scenarios. Compared with the typical binary Merkle tree structure, the N-ary Merkle tree significantly reduces the height of the Merkle tree by allowing a single node to carry more branches (for example, when N = 4, each parent node manages 4 child nodes), thereby reducing the hierarchical depth of hash calculations. When adding the first leaf node, recursively update the parent nodes layer by layer upward from the leaf node layer (the 0th layer). Among them, if the number of children nodes of the current parent node cannot be divisible by N due to the newly added node, then M placeholder child nodes need to be added (for example, when N = 4 and the parent node has 3 child nodes, then 1 placeholder child node needs to be added) so that the number of child nodes meets the requirement of being an integer multiple of N. The placeholder child nodes are usually filled with preset values to maintain the regularity of the N-ary Merkle tree structure and avoid hash calculation deviations caused by missing branches. The parent node calculates and updates its own hash value according to the hash values of all its included child nodes, and this update process is passed layer by layer to the root node, finally completing the update of the entire N-ary Merkle tree.

[0091] After completing the update of the Merkle tree and obtaining the updated root hash value, in step S405, store the root hash value into the state of the first account.

[0092] As described above, in the account status, a data field is designed to store the Merkle root node hash value corresponding to the account. The updated Merkle root hash value is stored in this field as a compact representation of the transactions related to this account.

[0093] In addition, according to one implementation, in the status of the first account, it may further include: a transaction count field for indicating the number of transactions sent. During the process of updating the account status, the maximum sequence number value in the Merkle tree leaf nodes can also be stored in the transaction count field. Since the Merkle tree corresponds to a single account, the transaction sequence number values it contains have the property of monotonically increasing, and the transaction sequence numbers of the transactions generated by the account are incrementally generated according to a certain rule. Therefore, in the account status, the transaction sequence number of the latest transaction generated by the account can be saved, and this transaction sequence number is the maximum sequence number value in the Merkle tree leaf nodes corresponding to the account status. Storing the maximum transaction sequence number in the current account status in the transaction count field can conveniently track the transaction activities of the account without traversing the transaction history, ensure that the sequence number values of each new transaction conform to the increment rule, and effectively prevent problems such as transaction replay attacks and double-spending.

[0094] The above is a detailed elaboration of a method for updating the account status in a blockchain provided by the embodiments of this specification. In the account status updated based on this method, it may include a data field for storing the Merkle root hash value. The Merkle tree associated with this field stores the summary information of the transactions of this account, thereby providing more efficient transaction queries for the account. Based on this, in some other embodiments of this specification, a method for querying transactions in a blockchain is also provided. Figure 5 The flow diagram of the method is given.

[0095] Referring to the accompanying drawings, in step S501 of this method: Receive a query request for a target transaction. The query request may carry relevant information about the target transaction, such as the transaction hash value, the transaction sequence number value nonce, etc. These information will be used for subsequent transaction queries.

[0096] Next, in step S503: Obtain the Merkle tree corresponding to the sending account of the target transaction. According to the account information provided in the query request, the sending account of the target transaction can be located, and the Merkle tree corresponding to this account can be obtained through the Merkle root hash stored in the sending account status.

[0097] Finally, in step S505: Determine the target leaf node corresponding to the target transaction in the Merkle tree according to the sequence number value nonce of the target transaction. According to the sequence number value of the target transaction provided in the query request, it can be searched and matched in the Merkle tree. Since the leaf nodes of the Merkle tree have been sorted in an orderly manner according to the sequence number values of each transaction when added, during query, the retrieval algorithm (for example, binary search method) can be used to quickly locate the target leaf node corresponding to the target transaction sequence number value, and then obtain the detailed information of the target transaction. For example, the block number of the block to which the target transaction belongs and the transaction index, etc., abandoning the random query method of using the transaction hash value to index data in the related art, thus realizing the quick query of the target transaction.

[0098] As described above, the transaction query method utilizes the structural characteristics of the Merkle tree associated with the account status, and quickly locates through the transaction sequence number value, improving the query efficiency. At the same time, due to the immutable characteristics of the Merkle tree and the uniqueness of the hash value, it can also provide real-time simple payment verification while quickly querying the target transaction.

[0099] According to one implementation, in the Merkle tree (i.e., the Merkle tree corresponding to the target transaction sending account), extract the hash values of each associated node on the Merkle path corresponding to the target leaf node. Perform simple payment verification on the target transaction according to the hash value of the target transaction, the hash values of the associated nodes, and the hash value of the Merkle root node of the Merkle tree.

[0100] Specifically, starting from the target leaf node, along the Merkle path from the target leaf node back to the root node of the Merkle tree, extract the hash values of each associated node on the path. The hash values of these associated nodes constitute the Merkle proof of the target transaction.

[0101] Next, combine the transaction hash value of the target transaction and the hash values of these associated nodes, and recalculate the root hash value according to the hash calculation rules of the Merkle tree, and compare it with the Merkle root hash value stored in the account status of the target transaction sending account. If the two are consistent, it proves that the target transaction indeed exists in this Merkle tree, thus completing the simple payment verification of the target transaction.

[0102] From the descriptions of the above embodiments, it can be seen that when updating the account status, by storing the summary information of the transaction in the Merkle tree and associating the Merkle root node with the account status, it is possible to embed historical transaction traceability information in the account status, while decoupling the transaction summary information from the account status to achieve lightweight data updates. In addition, through this Merkle tree, fast transaction queries can be provided for the account, and simple payment verification of the transaction can also be performed. It avoids random reading and writing of transaction hashes and also avoids the overall traversal of the transaction list, thereby improving the system performance of the blockchain network.

[0103] In this specification, the "first" in terms such as the first account and the first transaction, and the corresponding "second", "third" (if any) in the text are only for the convenience of distinction and description and do not have any restrictive meaning.

[0104] The above content describes specific embodiments of this specification, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be executed in a different order from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily have to be in the specific order or continuous order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0105] Figure 6 It is a schematic diagram of a device for updating an account status in a blockchain according to an embodiment of this specification. The device 600 is deployed in a computing device, and the computing device can be implemented by any device, equipment, platform, device cluster, etc. with computing and processing capabilities. This system embodiment corresponds to Figure 4 the method embodiment shown. The device 600 includes:

[0106] An adding module 601, configured to, in response to the completion of the execution of a first transaction sent by a first account, obtain the Merkle tree corresponding to the first account, and add a first leaf node corresponding to the first transaction to the Merkle tree, where the first leaf node at least includes the sequence number value nonce and the transaction hash value of the first transaction.

[0107] An updating module 602, configured to update the Merkle tree based on the first leaf node to obtain an updated root hash value.

[0108] A storing module 603, configured to store the root hash value into the status of the first account.

[0109] Figure 7 A schematic diagram of a device for querying transactions in a blockchain according to an embodiment of this specification. The device 700 is deployed in a computing device, which can be implemented by any device, equipment, platform, device cluster, etc. with computing and processing capabilities. This system embodiment corresponds to Figure 5 the method embodiment shown. The device 700 includes:

[0110] A receiving module 701, configured to receive a query request for a target transaction.

[0111] An obtaining module 702, configured to obtain the Merkle tree corresponding to the sending account of the target transaction, and the Merkle tree is updated by the device of claim 8.

[0112] A determining module 703, configured to determine the target leaf node corresponding to the target transaction in the Merkle tree according to the sequence number value nonce of the target transaction.

[0113] Those skilled in the art should be able to realize that in one or more of the above examples, the functions described in the embodiments of the present invention can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0114] The above-described specific embodiments have further detailed the purpose, technical solution, and beneficial effects of the embodiments of the present invention. It should be understood that the above is only the specific embodiments of the embodiments of the present invention and is not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present invention should be included in the protection scope of the present invention. < / k3-v3> < / k2-v2> < / k1-v1>

Claims

1. A method for updating an account status in a blockchain, comprising: In response to completion of execution of a first transaction sent by a first account, obtaining a Merkle tree corresponding to the first account, and adding a first leaf node corresponding to the first transaction to the Merkle tree, wherein the first leaf node includes at least a sequence number value nonce and a transaction hash value of the first transaction; Based on the first leaf node, updating the Merkle tree to obtain an updated root hash value; The root hash value is stored in the state of the first account.

2. The method according to claim 1, wherein: The multiple leaf nodes of the Merkle tree are arranged from left to right in the tree from small to large according to the serial number values ​​of their corresponding transactions; The adding a first leaf node corresponding to the first transaction in the Merkle tree includes: Add the first leaf node at the rightmost side of the Merkle tree leaf node layer.

3. The method according to claim 1, wherein: The first leaf node also includes the block number of the block to which the first transaction belongs and the transaction index number in the block.

4. The method according to claim 1, wherein: The state of the first account includes: a transaction count field for indicating the number of transactions sent; the method further includes: The maximum sequence number value in the Merkle tree child node is stored in the transaction count field.

5. The method according to claim 1, wherein: The Merkle tree is an N-fork Merkle tree structure; in response to the addition of the first leaf node, updating the Merkle tree includes i rounds of layer-by-layer updates starting from the 0th layer of the Merkle tree, where the 0th layer is a leaf node layer and the ith layer is a root node layer, wherein any round of updates includes: Performing a first update on a first parent node of a current processing layer, wherein the child nodes of the first parent node include: an updated node, and / or a newly added node; the newly added node includes: M newly added placeholder child nodes, so that the number of child nodes of the first parent node can be divided by N; the first update includes updating the hash value of the node according to the hash values ​​of all child nodes included in the node; The next layer of the current processing layer is used as the processing layer for the next round of updates.

6. A method for querying transactions in a blockchain, comprising: Receiving a query request for a target transaction; Obtaining a Merkle tree corresponding to the target transaction sending account, wherein the Merkle tree is updated by the method of any one of claims 1 to 5; According to the sequence number value nonce of the target transaction, a target leaf node corresponding to the target transaction in the Merkle tree is determined.

7. The method according to claim 6, wherein: The method further comprises: In the Merkle tree, extract the hash values ​​of each associated node on the Merkle path corresponding to the target leaf node; Perform simple payment verification on the target transaction according to the hash value of the target transaction, the hash value of the associated node, and the hash value of the Merkle tree root node.

8. A device for updating an account status in a blockchain, comprising: an adding module configured to, in response to completion of execution of a first transaction sent by a first account, obtain a Merkle tree corresponding to the first account, and add a first leaf node corresponding to the first transaction in the Merkle tree, wherein the first leaf node includes at least a sequence number value nonce and a transaction hash value of the first transaction; An updating module, configured to update the Merkle tree based on the first leaf node to obtain an updated root hash value; A storage module is configured to store the root hash value in the state of the first account.

9. A device for querying transactions in a blockchain, comprising: A receiving module configured to receive a query request for a target transaction; An acquisition module configured to acquire a Merkle tree corresponding to the target transaction sending account, wherein the Merkle tree is updated by the device of claim 8; The determination module is configured to determine a target leaf node corresponding to the target transaction in the Merkle tree according to the sequence number value nonce of the target transaction.

10. A computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 7 is implemented.

Images