A method of creating an account in a blockchain and a blockchain node

Abstract

A method of creating an account in a blockchain and a blockchain node, the blockchain node storing mapping relationship information of account addresses and account numbers of a plurality of accounts, the method comprising: when writing an account state of a first account, in a case where an account number corresponding to the first account address is not found according to the mapping relationship information, determining a first account number of the first account; adding a mapping relationship of the first account address and the first account number in the mapping relationship information; adding a first leaf node corresponding to the first account in a Merkle state tree, a key of the first leaf node being the first account number, and a value of the first leaf node being the account state of the first account; and in response to the addition of the first leaf node, updating the Merkle state tree.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for creating an account on a blockchain and a blockchain node. Background Technology

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

[0003] The purpose of this invention is to provide a scheme for creating accounts in a blockchain that saves storage space and improves access efficiency.

[0004] This specification provides, in a first aspect, a method for creating an account in a blockchain, executed by a blockchain node, wherein the blockchain node stores mapping information between account addresses and account numbers of multiple accounts, and the method includes:

[0005] When writing the account status of the first account, if the account number corresponding to the first account address is not found according to the mapping relationship information, the first account number of the first account is determined.

[0006] Add a mapping relationship between the first account address and the first account number to the mapping relationship information;

[0007] Add a first leaf node corresponding to the first account in the Merkel state tree. The key of the first leaf node is the first account number, and the value of the first leaf node is the account status of the first account.

[0008] In response to the addition of the first leaf node, the Merkel state tree is updated.

[0009] A second aspect of this specification provides a blockchain node, wherein the blockchain node stores mapping information between account addresses and account numbers of multiple accounts, and the blockchain node includes:

[0010] The determining unit is used to determine the first account number of the first account when the account status of the first account is written and the account number corresponding to the first account address is not found according to the mapping relationship information.

[0011] An adding unit is used to add a mapping relationship between the first account address and the first account number in the mapping relationship information; and to add a first leaf node corresponding to the first account in the Merkel state tree, wherein the key of the first leaf node is the first account number and the value of the first leaf node is the account status of the first account.

[0012] An update unit is used to update the Merkel state tree in response to the addition of the first leaf node.

[0013] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0014] A fourth aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0015] This specification provides an access scheme in a blockchain. By replacing the account address with an account number that has fewer bytes, and storing the account state in the Merkle state tree in association with the account number, the storage space used to store the account address in the blockchain can be reduced, the access performance of the state tree can be improved, and the account access speed can be accelerated. Attached Figure Description

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

[0017] Figure 1 A blockchain architecture diagram in one embodiment is shown;

[0018] Figure 2 This is a schematic diagram of a blockchain data storage structure.

[0019] Figure 3 This is a flowchart illustrating a method for creating an account in a status database according to an embodiment of this specification.

[0020] Figure 4 This is a schematic diagram of a data structure in a blockchain node as described in the embodiments of this specification.

[0021] Figure 5 This is a schematic diagram of the Merkle tree in the embodiments of this specification;

[0022] Figure 6 This is a flowchart illustrating the method for accessing account status in a blockchain as described in the embodiments of this specification.

[0023] Figure 7 This is a flowchart illustrating the method for deleting an account in a blockchain as described in the embodiments of this specification.

[0024] Figure 8 This is a diagram illustrating the processing of the ID corresponding to the deleted account after the account has been deleted.

[0025] Figure 9 This is an architecture diagram of a blockchain node in one of the embodiments of this specification. Detailed Implementation

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

[0027] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 In the blockchain architecture diagram shown, blockchain 100 includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transfer between nodes. These nodes can store the entire ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can produce the same state by executing the same transactions, and each node can store the same state database.

[0028] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0029] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0030] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1 In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0031] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0032] In various blockchain networks that have introduced smart contracts, Ethereum, for example, typically allows accounts to be divided into two types:

[0033] 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.

[0034] Externally owned account: A user's account, such as an Ethereum owner's account.

[0035] The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include fields such as nonce, balance, storageRoot, and codeHash. Nonce and balance exist in both external and contract accounts. The codeHash and storageRoot attributes are generally only valid for contract accounts.

[0036] nonce: A counter. For external accounts, this number represents the number of transactions sent from the account address; for contract accounts, it is the number of contracts created by the account.

[0037] balance: The amount of Ether held by this address.

[0038] storageRoot: The hash of the root node of an MPT tree that organizes the storage of state variables for contract accounts.

[0039] codeHash: The hash value of the smart contract code. For contract accounts, this is the code of the smart contract that has been hashed and stored; for external accounts, since the smart contract is not included, the codeHash field can generally be an empty string or a string of all zeros.

[0040] MPT stands for Merkle Patricia Tree, a tree structure that combines the features of a Merkle Tree and a Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each pair of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

[0041] The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs representing the storage content for each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (the Ethereum account address), distributed across storage nodes from the root to the leaf nodes. The "value" in the state trie is generated by encoding the Ethereum account information using recursive-length prefix encoding (RLP). As mentioned earlier, for external accounts, the values ​​include nonce and balance; for contract accounts, the values ​​include nonce, balance, codehash, and storageroot.

[0042] A contract account is used to store the state of a smart contract. Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has several states, defined by state variables within the smart contract and updated with new values ​​during the contract's creation and execution. A smart contract is usually a contract defined digitally in a blockchain environment that can automatically execute its terms. Once an event triggers a clause in the contract (meeting the execution conditions), the code can execute automatically. In the blockchain, the contract's state is stored in a storage trie. The hash value of the storage trie's root node is stored in the aforementioned storage root, thus locking all the contract's states to that contract account via hash. The storage trie is also an MPT tree structure, storing a key-value mapping from state addresses to state values. From the root node to the leaf node of the storage trie tree, the address of a state is stored; each leaf node stores the value of a state.

[0043] Figure 2 This is a schematic diagram of a blockchain data storage structure. Figure 2In some blockchain data storage examples, the block header of each block includes several fields, such as the previous block hash (prevHash in the diagram), a nonce (in some blockchain systems, this nonce is not random, or the nonce in the block header is not enabled), a timestamp, the previous block number (Block Num), the state root hash (State_Root), the transaction root hash (Transaction_Rooth), and the receipt root hash (Receipt_Rooth). The Prev Hash in the block header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the hash value of the previous block. In this way, the blockchain achieves locking of the previous block by the next block through the block header. Specifically, as mentioned earlier, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block; that is, pointing to state_root is an MPT-form state tree (state trie). The root node of this MPT tree is typically an extension node or a branch node, and `state_root` usually stores the hash value of this root node. A subset of values ​​from each node from the root to the leaf nodes are concatenated sequentially to form an account address, which serves as the key. The account information stored in the leaf nodes is the value corresponding to this account address, thus forming a key-value pair. Specifically, the key can be SHA3 (Address), i.e., the hash value of the account address (using a hash algorithm such as SHA3), and the stored value can be RLP (Account), i.e., the RLP encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. As mentioned earlier, for external accounts, generally only the nonce and balance fields are present, while the storageRoot and codeHash fields default to storing empty strings / strings of all zeros. That is to say, external accounts do not store contracts or the state variables generated after contract execution. A contract account typically includes nonce, balance, storageRoot, and codeHash. Nonce is the transaction counter for that contract account; balance is the account balance; storageRoot corresponds to another MPT (Multi-Level Transmission), which links to contract-related state information; and codeHash is the hash value of the contract code. Whether it's an external account or a contract account, its account information is generally located in a single leaf node.From the root node's ExtensionNode / Branch Node to each account's Leaf Node, there may be several branch nodes and extension nodes in between.

[0044] The state trie can be an MPT (Multi-Level Tree) tree, typically a 16-ary tree, with each level having a maximum of 16 child nodes and a maximum depth of 64 levels. Extension Nodes, used to store common prefixes, generally have one child node, which can be a Branch Node. Branch Nodes can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes. Such an MPT tree can have a maximum depth of 64 levels. When the number of accounts in the blockchain reaches a certain threshold, this MPT tree may approach or reach a depth of 64 levels.

[0045] For a contract account within the state trie, its `storage_root` points to another tree, also in MPT form, which stores data related to the contract's execution state variables. This `storage_root` points to an MPT-form tree called the Storage Trie, specifically the hash value of the root node. Generally, this Storage Trie also stores key-value pairs. Data stored along the path from the root node to a leaf node is concatenated to form the key, and the leaf node stores the value. As mentioned earlier, this Storage Trie can also be an MPT-form tree, typically a 16-ary tree. This means that a Branch Node can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes. An Extension Node typically has one child node, which can be a Branch Node. This Storage Trie tree can have a maximum depth of 64 levels.

[0046] like Figure 2As shown, each block in the blockchain corresponds to a state tree. For example, Block N corresponds to the Block N state tree, and Block N+1 corresponds to the Block N+1 state tree. Account states in the Block N+1 state tree that are identical to those in the Block N state tree can directly reference the account states (i.e., values) in the Block N state tree. However, account addresses in the blockchain typically occupy a significant amount of space, generally 32 bytes. With each block corresponding to a state tree, and each state tree containing various account addresses, the blockchain stores a large number of duplicate account addresses, consuming substantial storage space and impacting the speed of account state retrieval.

[0047] This specification provides an access scheme in a blockchain. By replacing the account address with an account number that has fewer bytes, and storing the account state in the Merkle state tree in association with the account number, the storage space used to store the account address in the blockchain can be reduced, the access performance of the state tree can be improved, and the account access speed can be accelerated.

[0048] Figure 3 This is a flowchart illustrating a method for creating an account in a state database, as described in an embodiment of this specification. This method is executed by each blockchain node in the blockchain.

[0049] like Figure 3 As shown, firstly, in S310, for the account to be written, if the account number corresponding to the account is not stored in the blockchain node, the account number is determined.

[0050] Suppose a user sends a transaction Tx1 to the blockchain to create an account Account1. Transaction Tx1 includes the account address of Account1, for example, "0a3fde2c13d7a…". After receiving transaction Tx1, the blockchain broadcasts it to all nodes. Each node then executes transaction Tx1, resulting in a write set containing key-value pairs for account Account1. The key is the account address of account Account1, and the value is the state of account Account1, used to write the state of account Account1 into the state database.

[0051] After completing the execution of transaction Tx1, any node in the blockchain (e.g., node 1) writes data to the state database according to the write set of transaction Tx1.

[0052] In the embodiments described in this specification, mapping information is stored in the blockchain nodes. This mapping information includes the correspondence between the account addresses of each created account and the account ID (hereinafter referred to as ID). The blockchain nodes also construct a Merkle state tree (hereinafter referred to as Merkle tree) in the state database using the account ID as the key to store the state of the account. The account ID is, for example, a monotonically increasing number starting from 1. In this way, even if the account data needs to be repeatedly written to the state database, the storage space is greatly saved because the number of bytes of the account ID is much smaller than that of the account address.

[0053] Figure 4 This is a schematic diagram of a data structure in a blockchain node as described in the embodiments of this specification. Figure 4 As shown, a mapping table between a preset prefix (Pre) of an account address and the account ID is stored in the memory of a blockchain node. For example, each cell in the mapping table stores the mapping relationship between the Pre and ID of an account address. In one implementation, the mapping table can be in the form of a hash table. Assuming the blockchain currently has less than 100,000 accounts, a number within a preset range (e.g., 0-100,000) is obtained by performing a specific hash calculation on the Pre of the account. The mapping table contains 100,000 tables, so the position of the table storing the mapping relationship of the account can be determined based on the number obtained by hashing the Pre of the account. Since the account address itself is very long, the cases where Pre are the same between account addresses are rare. Therefore, usually, one table in the mapping table corresponds to one account. In the case where several different account addresses have the same Pre, the table in the mapping table corresponding to that Pre can be pointed to a sub-mapping table. This sub-mapping table includes several tables, each corresponding to one of the several accounts, recording the correspondence between the Pre and ID of that account. This setting reduces the required memory storage space by recording only the Pre (instead of all account addresses) and ID in memory. At the same time, when blockchain nodes look up the ID corresponding to an account address in order to read the account status, for most accounts that do not have the same Pre as other account addresses, the ID corresponding to the account address can usually be found through the mapping table in memory, without having to read persistent media (such as hard drives), thus speeding up the lookup.

[0054] Address storage files are stored on the hard drive of each blockchain node. Each address storage file stores the account addresses of each account in order of their account IDs. Account addresses can be stored in multiple files on the hard drive. For example, file 1 could store the account addresses of 100 accounts with IDs from 1 to 100 in order, while file 2 could store the account addresses of each account starting with ID 101 in order, and so on. Figure 4The example only shows one address storage file. When searching for the ID corresponding to an account address, if the Pre of that account address corresponds to several IDs, the account address corresponding to each ID can be read from the address storage file based on those IDs. This allows determining whether each read account address includes the account address to be searched. If it does, then the ID corresponding to that account address can be determined. This is understandable. Figure 4 This specification only shows one specific example of the mapping relationship information in the embodiments of this specification, and the embodiments of this specification are not limited thereto.

[0055] In addition, the hard drive also stores a state database, which constructs a Merkel state tree using IDs as keys for each account. Figure 5 This is a schematic diagram of the Merkle tree used in the embodiments of this specification. Figure 5 As shown in the embodiments of this specification, the Merkle tree is a k-ary tree ( Figure 5 (A 4-ary tree is shown as an example).

[0056] The leaf nodes of a Merkle tree represent the account states of multiple accounts arranged in ascending order of their IDs. The key of a leaf node is the account ID, and the value is the account state, which may include, for example, account balance. In this Merkle tree, leaf nodes are called level 0 nodes, their parent nodes are called level 1 nodes, and so on. The key of a level 1 node includes the level number and the node number, for example, 1_2, where "1" represents level 1 and "2" represents the second node in level 1. The parent node's number is determined based on the numbers of its child nodes. Assuming the child node's number is j, if j is divisible by k, a parent node is added to the level above the child node, and the parent node's number is calculated as j / k. For example, see reference... Figure 5 Node 1_2 corresponds to the four nodes 5 to 8. The 2 in node 1_2 is obtained by calculating 8 / 4. The value of the parent node is calculated based on the hash values ​​of its child nodes.

[0057] refer to Figure 5 In a blockchain node, the data (key-value pairs) of each leaf node can be stored in a Level 0 node data storage file. Within this file, the leaf node data can be stored in ascending order of ID, allowing for quick retrieval of the corresponding leaf node based on its ID. Similarly, the data (key-value pairs) of each Level 1 node can be stored in a Level 1 node data storage file. Again, this file can be stored in ascending order of node number.

[0058] When a blockchain node writes the state of account Account1 according to the write set of transaction Tx1, it first checks the memory mapping table to see if Account1's Pre is stored. If Account1's Pre is not stored in the mapping table, it means this write to account Account1 is a creation operation. Alternatively, if the Pre exists in the mapping table, but the account address read from the address storage file based on the ID corresponding to Pre is inconsistent with the address of Account1, it also means this write to account Account1 is a creation operation. In both cases, this is the first write to account Account1, used to create the state of account Account1 in the state database. Since the blockchain node does not yet record the ID corresponding to account Account1, it needs to first determine the ID corresponding to account Account1.

[0059] To this end, the blockchain node can first determine if there are any idle IDs due to account deletion. If so, it can obtain the idle ID as the ID of account Account1. If not, the blockchain node can determine the currently used maximum ID. Assuming the currently used maximum ID is 19, the blockchain node can determine that the ID of account Account1 is 19 + 1 = 20.

[0060] In S320, blockchain nodes add a mapping relationship between account addresses and account numbers to the mapping relationship information.

[0061] After determining the ID of account Account1, the blockchain node determines the table corresponding to that Pre in the mapping table based on Account1 and reads that table. If the table is empty, the blockchain node stores Account1's Pre and ID in that table in association. Figure 4 The diagram illustrates storing the Pre "0a3fde" and ID "20" of Account1 in the mapping table.

[0062] If the table is not empty, it means that there is another account whose Pre is the same as Account1's Pre. Therefore, a sub-mapping table corresponding to this table can be created to store Account1's Pre and ID.

[0063] Next, the storage unit corresponding to ID=20 can be determined in the address storage file on the hard drive, and the account address "0a3fde2c13d7a…" of account Account1 can be stored in that storage unit. Assuming that each address storage file can store a maximum of 100 account addresses, the address storage file corresponding to account Account1 can be determined by calculating 20 / 100. The offset of the storage unit corresponding to ID=20%100 in the file can be determined by calculating the remainder. Therefore, the account address "0a3fde2c13d7a…" of account Account1 can be stored in the storage unit corresponding to ID=20 based on this offset.

[0064] In S330, the blockchain node adds a leaf node corresponding to account Account1 in the Merkle tree.

[0065] refer to Figure 5 Assuming that nodes 20, 21, 22, and 1_5 are not yet present in the Merkle tree, after the above operations, the blockchain node can store the state of account Account1 in the Merkle tree using the account ID as the key, i.e., "20: Nonce / Balance". After determining that account Account1 corresponds to ID=20, the blockchain node adds node 20 sequentially after node 19 in the Merkle tree. Specifically, the blockchain node can store the key-value pair of node 20 in the 20th storage unit of the layer 0 node data storage file, where key=20 and value includes Merkle tree Nonce, Balance, and other data.

[0066] In S340, blockchain nodes update the Merkle tree in response to the addition of leaf nodes.

[0067] refer to Figure 5For the newly added node 20, we calculate 20 / 4 = 5, meaning that the ID of node 20 is divisible by k (i.e., the number of forks). Therefore, the blockchain node adds a parent node for node 20 at level 1. This parent node includes four child nodes: node 17, node 18, node 19, and node 20. The key of this added parent node is 1_5, where 1 is the level number and 5 is the node number calculated above. The value of node 1_5 is a hash value calculated based on the hash values ​​of nodes 17, 18, 19, and 20, for example, H(H(17),H(18),H(19),H(20)), where H() indicates hash calculation of the data within the parentheses, the comma in H() indicates concatenation of the data before and after the comma, and H(17) indicates taking the hash value of the data of node 17. After adding parent node 1_5 to the Merkle tree, determine whether the node's number is divisible by 4. If it is, continue adding the parent node of the node. If it is not divisible by 4, stop adding nodes and update the root hash value of the Merkle tree based on the current node.

[0068] For example, in adding Figure 5 After node 22, if it is determined that the ID of node 22 is not divisible by 4, then no more nodes will be added, and the root hash value of the Merkle tree will be updated based on the current node, which is root = H(H(2_1),H(1_5),H(21),H(22)).

[0069] In the embodiments of this specification, by constructing a Merkle tree based on the account ID, when adding a node for a later-created account to the Merkle tree, it is not necessary to update the intermediate nodes corresponding to the already created accounts (i.e., the nodes between the root node and the leaf nodes), thus improving state storage efficiency. Additionally, refer to... Figure 5 The Merkle tree shown improves state access efficiency because it adds a parent node to the next level only when the node number at each level is divisible by k. This results in the same number of path levels for accessing most leaf nodes in the Merkle tree.

[0070] After creating an account in the blockchain node as described above, subsequent actions can be based on... Figure 4 The data structure shown allows access to account status, including reading or writing to the account status.

[0071] Figure 6 This is a flowchart illustrating the method for accessing account status in a blockchain, as described in the embodiments of this specification.

[0072] like Figure 6 As shown, firstly in S610, the blockchain node determines the account number corresponding to the account address based on the stored mapping relationship information.

[0073] When a blockchain node needs to read the state of an account for the first time during the execution of transactions on the blockchain, it performs a read operation on the state database for that account. Specifically, assuming transaction Tx2 needs to read the state of account Account1, the blockchain node first determines the ID corresponding to account Account1 based on the mapping relationship between account addresses and IDs stored in the blockchain node. (Reference) Figure 4 The blockchain node first obtains the Pre "0a3fde" of the account address of account Account1, calculates the hash value of "0a3fde" using a specific hash function, determines the position of the table in the mapping table based on this hash value, and then reads the table. Assuming the table contains... Figure 4 The table shows that only "Pre:0a3fde / ID:20" is stored, indicating that the ID in this table is the ID corresponding to Account1.

[0074] In another scenario, suppose the table is set to point to a sub-mapping table, which contains several tables, each with Pre set to "0a3fde". This indicates that the Pre values ​​of the account addresses corresponding to these tables are identical. In this case, the blockchain node can locate the storage unit in the address storage file based on the ID in each table, read the complete account address corresponding to each table, and thus determine the table that corresponds to the account address of Account1, thereby determining the ID corresponding to Account1.

[0075] In another scenario, assuming a blockchain node completes transaction Tx2, and the write set of transaction Tx2 includes writing the state of account Account1, the blockchain node, when writing according to the write set of transaction Tx2, can first look up the ID corresponding to account Account1 in the mapping relationship information to write it into the state database. Specifically, the blockchain node first looks up the Pre for Account1 in the mapping table in memory. If the Pre is found, and the Pre corresponds to only one ID, then it reads the account address corresponding to that ID from the address storage file. If the account address corresponding to that ID is the account address of Account1, then that ID is the ID of Account1. If the account address corresponding to that ID is not the account address of Account1, then this write is used to create Account1. Therefore, see [reference needed]. Figure 3 The process shown illustrates the account creation process.

[0076] If the Pre is found, and Pre corresponds to several IDs, then the account address corresponding to each ID is searched in the address storage file. If the account address corresponding to each ID includes the account address of Account1, then the ID corresponding to the account address of Account1 is determined as the ID of Account1. If the account address corresponding to each ID does not include the account address of Account1, then this write is used to create Account1. Therefore, please refer to... Figure 3 The process shown illustrates the account creation process.

[0077] In S620, blockchain nodes access account status based on account number.

[0078] In the scenario described above, where the state of account Account1 is being read, after the blockchain node determines that ID=20 corresponds to account Account1, it can use ID=20 as the key to search for the state corresponding to key=20 in the state database and return that state. For example, see [reference]. Figure 5 Similar to reading address storage files, blockchain nodes can determine the storage unit in the Level 0 node data storage file that stores the state corresponding to the ID based on the size of the ID, and read the state corresponding to the ID from that storage unit.

[0079] Blockchain nodes can also read proof data used for simple payment verification (SPV) of the read state. This proof data includes, for example, the data hashes of the following nodes: node 2_1, node 17, node 18, node 19, node 21, and node 22. Based on the proof data and the key-value pair of node 20, the root of the Merkle tree can be calculated to verify whether the read account state is correct.

[0080] In the scenario described above regarding updating the state of Account1, the blockchain node can, similar to reading the account state, determine the storage unit corresponding to ID=20 in the state database based on ID=20, and write the new state of account Account1 into that storage unit. Afterward, the blockchain node updates the Merkle tree based on the update from node 20. Specifically, it updates the values ​​of node 1_5 and the root node based on the updated value from node 20.

[0081] Figure 7 This is a flowchart illustrating the method for deleting an account in a blockchain, as described in the embodiments of this specification.

[0082] refer to Figure 7 In S710, in response to a request to delete account1, the blockchain node removes the account address prefix Pre and account number of account1 from the mapping table.

[0083] Specifically, the blockchain node determines the table in memory that stores the mapping relationship of account Account1 based on the Pre of account Account1, and deletes the Pre and its ID of account Account1 from the table.

[0084] In S720, blockchain nodes delete account addresses from the storage unit associated with account numbers.

[0085] Specifically, the blockchain node determines the storage unit corresponding to account Account1 in the address storage file based on account ID=20, and deletes the account address of account Account1 in that storage unit.

[0086] In S730, blockchain nodes delete the node corresponding to an account in the Merkle tree.

[0087] Specifically, a blockchain node can find the storage unit corresponding to ID=20 in the Merkle tree based on ID=20 of account1, and delete the account status of account1 in that storage unit.

[0088] After the above deletion is performed, the storage unit corresponding to ID=20 in the address storage file and status database becomes an idle storage unit. To save storage space, the ID corresponding to the deleted account can be reused. Figure 8 This is a diagram illustrating the processing of the ID associated with a deleted account after the account has been deleted. (Reference) Figure 8After deleting account Account1, the value of the variable "Latest Deleted ID" stored on the hard drive is read. Assuming the current value of this variable is "6", and the storage unit for ID=6 in the address storage file stores "4", this indicates that the latest deleted account before ID=20 corresponds to ID 6, and the deleted account before ID=6 corresponds to ID 4. Then, the blockchain node records ID=20 in the variable "Latest Deleted ID" and records "6" in the storage unit for ID=20 in the address storage file. Through this operation, the latest deleted ID points to the storage unit for ID=20 in the address storage file through its recorded value, the storage unit for ID=20 in the address storage file points to the storage unit for ID=6 in the address storage file through its recorded value, and the storage unit for ID=6 in the address storage file points to the storage unit for ID=4 in the address storage file through its recorded value 4, thus forming a linked list of IDs corresponding to deleted accounts. This effectively reuses the IDs of deleted accounts. When a blockchain node needs to determine the corresponding ID for a newly created account, it first reads the value of the variable "Latest Deleted ID". If the variable is empty, it means there is no ID for a deleted account, and a new ID can be generated for the newly created account. If the variable is not empty, for example, if it is 20, indicating that ID=20 can be reused, the blockchain node can reassign ID=20 to the newly created account, and update the value of the variable "Latest Deleted ID" to "6" according to the value 6 recorded in the storage unit corresponding to ID=20 in the address storage file, so that the blockchain node can assign ID=6 to the next newly created account.

[0089] Figure 9 This is an architecture diagram of a blockchain node according to an embodiment of this specification. The blockchain node stores mapping information between account addresses and account numbers of multiple accounts. The blockchain node includes:

[0090] The determining unit 91 is used to determine the first account number of the first account when the account status of the first account is written and the account number corresponding to the first account address is not found according to the mapping relationship information.

[0091] Adding unit 92 is used to add a mapping relationship between the first account address and the first account number in the mapping relationship information; add a first leaf node corresponding to the first account in the Merkel state tree, where the key of the first leaf node is the first account number and the value of the first leaf node is the account status of the first account.

[0092] Update unit 93 is used to update the Merkel state tree in response to the addition of the first leaf node.

[0093] In one embodiment, the adding unit 92 is specifically used for:

[0094] The first prefix and the first account number in the first account address are stored in association in a mapping table in memory;

[0095] The address of the first account is stored in persistent media in association with the first account number.

[0096] In one embodiment, the determining unit 91 is specifically used for:

[0097] Obtain the current maximum account number, and increment the maximum account number by one to obtain the first account number.

[0098] In one implementation, the multiple leaf nodes of the Merkel state tree are arranged from left to right in the Merkel state tree according to the account number in ascending order, and the adding unit 92 is specifically used for:

[0099] Add the first leaf node to the far right of the Merkel state tree.

[0100] In one implementation, the Merkel state tree is a k-ary tree, and the adding unit 92 is specifically used for:

[0101] For the j-th newly added node in the i-th layer of the Merkle state tree, determine whether j is divisible by k, where the leaf node is the 0th layer in the Merkle state tree, and the parent node has one more layer than its child node.

[0102] In cases where j is divisible by k, the parent node of the j-th node is added at the (i+1)-th level. The key of the added parent node includes the level number i+1 and j / k, and the value of the added parent node is generated based on the hash values ​​of all its child nodes.

[0103] In one embodiment, the updating unit 93 is further configured to:

[0104] If the mapping relationship information indicates that the first account address corresponds to the first account number, the account status of the first account is updated in the Merkel state tree according to the first account number.

[0105] In one implementation, the persistent medium of the blockchain node is provided with a plurality of storage units arranged in sequence, and the plurality of storage units store the plurality of leaf nodes in the Merkel state tree in ascending order according to the plurality of account numbers corresponding to the plurality of leaf nodes.

[0106] In one embodiment, the blockchain node further includes a lookup unit, configured to, in response to a read operation on the account status of the first account, search in the mapping table according to the first prefix of the first account address of the first account, and if the mapping table stores an account number corresponding to the first prefix, determine that account number as the first account number.

[0107] In one embodiment, the determining unit is further configured to: in the case where the mapping table stores a plurality of second account numbers corresponding to the first prefix, obtain the complete account address corresponding to each second account number from the persistent medium, and determine the first account number from among the plurality of second account numbers based on the complete account address corresponding to each second account number.

[0108] In one implementation, the blockchain node further includes a deletion unit, configured to, in response to a deletion request for the first account, delete the first prefix and the first account number in the mapping table; delete the account address of the first account in the first storage unit corresponding to the first account in the persistent medium; delete the first leaf node in the Merkle state tree; and update the Merkle state tree in response to the deletion of the first leaf node.

[0109] In one implementation, the blockchain node further includes an acquisition unit for acquiring the value of a first variable stored in a persistent medium, the value of which is currently a third account number, the third account number being the account number of the most recently deleted account before the first account was deleted.

[0110] The update unit is further configured to update the value of the first variable to the first account number and store the third account number in the first storage unit.

[0111] In one implementation, the determining unit is further configured to read the value of the first variable and use the read value of the first variable as the first account number of the first account.

[0112] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 3 , Figure 6 and Figure 7 The method shown.

[0113] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 3 , Figure 6 and Figure 7 The method shown.

[0114] This specification provides an access scheme in a blockchain. By replacing the account address with an account number that has fewer bytes, and storing the account state in the Merkle state tree in association with the account number, the storage space used to store the account address in the blockchain can be reduced, the access performance of the state tree can be improved, and the account access speed can be accelerated.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for creating an account in a blockchain, executed by a blockchain node, wherein the blockchain node stores mapping information between account addresses and account numbers for multiple accounts, wherein the number of bytes in the account number is less than the number of bytes in the account address; the method includes: When writing the account status of the first account, if the account number corresponding to the first account address of the first account is not found according to the mapping relationship information, the first account number of the first account is determined. Add a mapping relationship between the first account address and the first account number to the mapping relationship information; Add a first leaf node corresponding to the first account in the Merkel state tree. The key of the first leaf node is the first account number, and the value of the first leaf node is the account status of the first account. In response to the addition of the first leaf node, the Merkel state tree is updated.

2. The method according to claim 1, wherein adding the mapping relationship between the first account address and the first account number to the mapping relationship information comprises: The first prefix and the first account number in the first account address are stored in association in a mapping table in memory; The address of the first account is stored in persistent media in association with the first account number.

3. The method according to claim 1 or 2, wherein determining the first account number of the first account includes: Obtain the current maximum account number, and increment the maximum account number by one to obtain the first account number.

4. The method according to claim 3, wherein the multiple leaf nodes of the Merkel state tree are arranged from left to right in the Merkel state tree in ascending order of account number, and adding a first leaf node corresponding to the first account in the Merkel state tree includes: Add the first leaf node to the far right of the Merkel state tree.

5. The method according to claim 4, wherein the Merkle state tree is a k-ary tree, and the step of updating the Merkle state tree in response to the addition of the first leaf node includes: For the j-th newly added node in the i-th layer of the Merkle state tree, determine whether j is divisible by k, where the leaf node is the 0th layer in the Merkle state tree, and the parent node has one more layer than its child node. In cases where j is divisible by k, the parent node of the j-th node is added at the (i+1)-th level. The key of the added parent node includes the level number i+1 and the index j / k. The value of the added parent node is generated based on the hash values ​​of all its child nodes.

6. The method according to claim 2, further comprising: In the case where the first account address is found to correspond to the first account number based on the mapping relationship information, the account status of the first account is updated in the Merkel state tree according to the first account number; In response to an update to the account status of the first account, the Merkel state tree is updated.

7. The method according to claim 6, wherein the persistent medium of the blockchain node is provided with a plurality of storage units arranged in sequence, and the plurality of storage units store the plurality of leaf nodes in ascending order according to the plurality of account numbers corresponding to the plurality of leaf nodes in the Merkel state tree.

8. The method according to claim 7, further comprising: In response to the read operation of the account status of the first account, the first prefix of the first account address of the first account is searched in the mapping table. If the mapping table stores a first account number corresponding to the first prefix, the account status of the first account is read from the Merkle state tree according to the first account number.

9. The method of claim 8, further comprising: In the case where the mapping table stores multiple second account numbers corresponding to the first prefix, the complete account address corresponding to each second account number is obtained from the persistent medium. Based on the complete account address corresponding to each second account number, the first account number is determined from among the multiple second account numbers. Based on the first account number, the account status of the first account is read from the Merkle state tree.

10. The method according to claim 2, further comprising: In response to the deletion request for the first account, the first prefix and the first account number are deleted from the mapping table; The account address of the first account is deleted from the first storage unit corresponding to the first account in the persistent medium; Delete the first leaf node in the Merkel state tree; In response to the deletion of the first leaf node, the Merkel state tree is updated.

11. The method of claim 10, further comprising: Retrieve the value of a first variable stored in persistent media, the value of which is currently a third account number, which is the account number of the most recently deleted account before the first account was deleted. The value of the first variable is updated to the first account number, and the third account number is stored in the first storage unit.

12. The method according to claim 11, wherein determining the first account number of the first account comprises reading the value of the first variable and using the read value of the first variable as the first account number of the first account.

13. A blockchain node, wherein a mapping relationship information of account addresses and account numbers of a plurality of accounts is stored in the blockchain node, a number of bytes of the account numbers is less than a number of bytes of the account addresses. The blockchain nodes include: The determining unit is used to determine the first account number of the first account when the account status of the first account is written and the account number corresponding to the first account address of the first account is not found according to the mapping relationship information. An adding unit is used to add a mapping relationship between the first account address and the first account number in the mapping relationship information; and to add a first leaf node corresponding to the first account in the Merkel state tree, wherein the key of the first leaf node is the first account number and the value of the first leaf node is the account status of the first account. An update unit is used to update the Merkel state tree in response to the addition of the first leaf node.

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

15. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-12.

Images