Business data storage method in block chain system

Abstract

The invention provides a business data storage method in a block chain system. The method comprises the steps that a block chain node acquires business data of a to-be-executed business and an account identifier for executing the business; acquiring account data corresponding to the account identifier from a database; determining a service identifier of the service according to a service identifier of each historical service recorded in the account data, and obtaining data required by consensus based on the service identifier of each historical service executed by the account recorded in the account data so as to determine to-be-consensus information of the service; and in response to passing of the consensus of the to-be-consensus information, determining a globally unique query identifier for querying the service based on the account identifier and the service identifier of the service, and updating the account data in the database.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and in particular, to a method for storing business data in a blockchain system. 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 tamper-proof and non-forgeable is guaranteed by cryptographic means. Due to the characteristics of decentralization, information immutability, and autonomy of the blockchain, the blockchain has received more and more attention and applications.

[0003] In the prior art, when both parties in a business in a blockchain system execute the business, a unique Hash value corresponding to the business is generated, and the business data of the business is stored on the blockchain in the form of <Hash, block number + transaction position>. When it is necessary to progress other businesses based on this business data for consistency, the corresponding transaction content can be obtained by parsing the block number.

[0004] However, since the nodes in the blockchain also need to store the ledger locally, and the Hash value corresponding to the business is pure random data, a large amount of data overhead is easily generated in the process of storing and using the business data. For example, in a database using the RocksDB engine, the compaction mechanism that originally reduces fragmented files and recycles space to improve storage efficiency continuously generates a large number of small SSTable files as the database continuously writes small batches of new business Hashes, and the burden of compaction will also increase accordingly. And the business Hash value is randomly generated data, and each write creates a new key-value pair instead of overwriting the existing record, resulting in a decrease in query performance.

[0005] Based on this, this specification provides a method for storing business data in a blockchain system to solve the problems existing in the prior art. Summary of the Invention

[0006] In view of this, this specification provides a method for storing business data in a blockchain system to solve the deficiencies existing in the related art.

[0007] Specifically, this specification is implemented through the following technical solutions:

[0008] According to the first aspect of the embodiments of this specification, a method for storing business data in a blockchain system is provided, including:

[0009] A blockchain node obtains the business data of a business to be executed and the account identifier for executing the business;

[0010] Acquire account data corresponding to the account identifier from a database;

[0011] Determine the business identifier of the business according to the business identifier of each historical business recorded in the account data, and obtain the data required for consensus based on the business identifier of each historical business executed by the account recorded in the account data, so as to determine the information to be agreed upon of the business;

[0012] In response to the consensus on the information to be agreed upon being passed, a globally unique query identifier for querying the service is determined based on the account identifier and the service identifier of the service, and the account data is updated in the database.

[0013] According to a second aspect of an embodiment of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method described in the first aspect are implemented.

[0014] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the steps of the method described in the first aspect are implemented.

[0015] According to a fourth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which implements the steps of the method described in the first aspect when executed by a processor.

[0016] In the technical solution provided in this specification, the blockchain node in the blockchain system constructs a query identifier with an account identifier and a business identifier of each business as a globally unique identifier for querying the business. When the account data is stored in the local database of the node, not only the number of transactions of the account is stored, but the query identifier of each business executed by the account and the storage address of each business on the blockchain are stored, so that when updating the database, there is no need to consider a series of problems caused by the hash value constructed by a pure random number. It is equivalent to providing a new account model of blockchain accounts, in which not only the information of the most recent business indexed by a random number is stored, but the information of each business is recorded with an account identifier and a business identifier recorded in sequence. The database used to store account data in the blockchain node is more in line with the optimization mechanism of the existing high-performance database, and the query efficiency is effectively guaranteed. Even if the account data of a large number of accounts needs to be recorded, the database will not generate a large amount of data consumption due to the random number index. The performance of the database of the blockchain node can be effectively improved and the operating cost can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a flowchart of a method for storing business data in a blockchain system shown in an exemplary embodiment of this specification;

[0018] Figure 2 is a schematic diagram of an account data structure shown in an exemplary embodiment of this specification;

[0019] Figure 3 is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of this specification;

[0020] Figure 4 It is a structural diagram of a business data storage device in a blockchain system shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0021] At present, in the blockchain system that adopts the Account Model, the status information of the account is stored in the global state tree of the blockchain. This state tree is usually a Merkle Patricia tree, which organizes all accounts and their related information into an efficient data structure, and its root hash is recorded in each block header to ensure the immutability and integrity of the state. Among them, the global state tree contains the information of all accounts, including but not limited to: account balance, number of transactions, storage root, and code hash. The account balance is the amount of cryptocurrency held by the account. The number of transactions is used for externally owned accounts (EOA) to indicate how many transactions have been sent, and for contract accounts to indicate how many sub-contracts have been created. The storage root points to another Merkle Patricia tree, which is used to store the state variables inside the contract account. The code hash is generally the hash value of the smart contract code and is only valid for the contract account.

[0022] Whenever a business is executed, if the business changes the status of an account (such as transferring money, calling a contract function, etc.), the corresponding node will be updated in the state tree. In order to maintain consistency, a new state tree root hash is calculated after each state change and recorded in the header of the new block.

[0023] Generally speaking, in order to improve blockchain performance, blockchain nodes usually maintain a complete copy of the state locally in order to quickly respond to query requests. These blockchain nodes synchronize the latest blocks and update their local states in real time. Some light clients, such as wallet clients, do not save all historical data or states, but rely on trust assumptions and other mechanisms to obtain necessary state information. They mainly focus on block headers and proofs on specific paths to verify the status of certain accounts. At the same time, archive nodes may also be set up in the blockchain system. Archive nodes not only save the current state, but also retain all historical state snapshots, which is very important for applications that need to access old states, such as browser tools or audit services.

[0024] In summary, in the account model, account information is not directly stored in a single file or database table, but is scattered throughout the blockchain network and maintained by all participating nodes in a complex distributed state tree. This approach not only ensures decentralization, but also provides sufficient security and efficiency to support various application scenarios.

[0025] However, in order to improve data storage performance, existing blockchain nodes usually introduce high-performance database engines. However, in the existing account model, data is stored with the hash value of the business as the index. As described in the background technology, there are a series of performance and cost issues. To solve the existing problems, this specification provides a method for storing business data in a blockchain system.

[0026] Specifically, in database engines such as RocksDB, the compaction mechanism is an important operation for maintaining data structures. It reduces disk space usage and optimizes read and write performance by merging and compressing data files. In RocksDB, compaction merges data from multiple SSTable files into one or fewer files, while deleting duplicate or expired data. However, in a blockchain system that uses the hash value of a business as a business index or business identifier, since the hash value of a business is generated by a cryptographic hash algorithm for the business content, they are almost completely random. This means that each time a new record is inserted, the key-value pair will be scattered throughout the key space, resulting in the business in the database's key space not being continuously related. Due to the randomness of the hash value of the above-mentioned business, the new key-value pair is unlikely to be adjacent to the existing data, resulting in each new insertion triggering a small-scale compaction. Over time, this frequent small-scale compaction will accumulate into a large-scale compaction event. Ultimately, a large number of compactions not only increase the I / O load, but may also lead to excessive consumption of CPU and memory resources, affecting the performance of the overall system. Although frequent compactions help keep data compact, they may also cause temporary waste of disk space due to failure to clean up old versions in a timely manner. Excessive compaction activities will affect the response time and throughput of the database, especially in the case of high concurrent writes.

[0027] On the other hand, hash values ​​are random numbers, so for the business data of the same account, even after Compaction optimization, the data is still distributed in different SSTables, which requires scanning multiple files when looking for a specific transaction, increasing the addressing time. In addition, the random access mode reduces the effectiveness of the page cache, because each query may involve data in different areas, reducing the cache hit rate and further slowing down the query speed. Furthermore, in order to speed up random queries, additional indexes are usually required, but this introduces more storage and maintenance costs. The above problems are all caused by the account model using the hash value of the business as the index or business identifier. It can be seen that the performance impact on the blockchain system is more obvious in scenarios with high concurrency and large business volume.

[0028] In addition, in the blockchain system provided in this specification, the blockchain node is used as an example to store business data. In fact, the light client is selected for data storage, and the above problems usually do not exist. The archiving node is not necessary to be set up, and data can also be stored according to the method provided in this specification. The process is consistent with the process of blockchain node data storage. This specification will not repeat this, that is, each historical state snapshot is stored using the method provided in this specification.

[0029] Based on this, this specification proposes a business data storage solution suitable for a blockchain system, which is described in detail below with reference to the accompanying drawings.

[0030] Figure 1 This is a flowchart of a method for storing business data in a blockchain system, as shown in an exemplary embodiment of this specification. Figure 1 As shown, the method may include the following steps:

[0031] Step 100: The blockchain node obtains the business data of the business to be executed and the account identifier for executing the business.

[0032] In one or more embodiments of this specification, any blockchain node in the blockchain system can be used as the subject of executing the business, obtain the business to be executed and the business data of the business to be executed, and the business data of the business to be executed at least includes the account identification of both parties to the business. In order to simplify the description, in this specification, the account identification of the account that initiates the business is used as an example for subsequent description. Of course, it should be noted that if other accounts that execute the business also have account data that needs to be stored, the same process can also be performed to determine the business data that needs to be stored and store it.

[0033] Specifically, the blockchain node can obtain the business data of the business to be executed, and the business data at least includes the account identification of the business initiator and the account identification of the recipient. Among them, the account identification usually refers to the account address, which is a unique identifier used to distinguish different accounts. This address is usually an encrypted hash value to ensure uniqueness and non-tamperability. The business data can also include the business content to be executed. Taking the business as a transfer business as an example, the business content to be executed can be the amount to be transferred, or the smart contract address to be triggered. Of course, the above content needs to include the signature of the initiator to ensure the validity of the business data.

[0034] Of course, since consensus needs to be reached based on business data in the blockchain, that is, the account status on which the business is executed, the blockchain node also needs to determine the business identifier of the business. In this specification, the business identifier can be a business serial number (nonce). The business identifier can be used to indicate how many transactions a certain account has sent. The use of a "transaction counter" or "transaction sequence number" can clearly convey that nonce is an increasing value used to ensure that transactions are executed in order and to prevent replay attacks. Therefore, the blockchain node needs to obtain account data through the account identifier to determine the business identifier.

[0035] Step 102: Acquire account data corresponding to the account identifier from a database.

[0036] As mentioned above, the blockchain node needs to obtain the account data of the account corresponding to the account identifier from the locally stored blockchain ledger to determine the business identifier to be executed, and also needs to obtain other business data required for consensus.

[0037] Specifically, the blockchain node can determine the storage address of the account data of the account identifier from the global state tree stored in the local database. Generally speaking, the global state tree is a data structure used to save the current status of all accounts in the blockchain, usually in the form of a Merkle Patricia Trie (MPT), which is an optimized prefix tree (Trie) suitable for efficient key-value pair lookup. Of course, the blockchain node in this specification is a full-featured node, so the node stores the Merkle tree locally.

[0038] The blockchain node can start from the Merkle tree root node and traverse downward layer by layer according to the account identifier. Each step determines the next branch according to a part of the account identifier until a leaf node is reached. When a leaf node is reached, the node stores the specific status information associated with the account identifier, that is, the account data, including balance, nonce, contract code, etc.

[0039] After determining the leaf node corresponding to the account, the account data of the account that was last updated can be obtained from the database. In this specification, the account model of the account data is as follows: Figure 2 shown.

[0040] exist Figure 2As can be seen in the figure, the account model contains a data set required for storing business, which contains the business identifiers of the account from the first business to the business executed after the most recent consensus, and each business identifier corresponds to the block number (block) where the business data is located, and the business index (index) in the block. The account data not only contains the business identifier and corresponding block number and business index of the most recent business, but also contains these data corresponding to all the businesses that have passed consensus on the account, and the unique identifier of the business is no longer based on the hash value determined by the business data. Therefore, when the database stores the Merkle tree, it can avoid storing a large number of random numbers, that is, there is no need to store a large number of hash values ​​corresponding to the business. When querying the business, it can also determine a specific business of a specific account according to the account identifier + business identifier. Under the premise of ensuring that the business can be executed normally, the complexity of storing data in the database is reduced. At the same time, compared with querying random numbers, the method of querying account identifier + business identifier can also greatly improve the database query speed.

[0041] For example, suppose an account has a transaction with a nonce of 3 and the corresponding block number is block 100 with a transaction index of 5. This means: since the nonce is 3, this transaction is from an account that has sent three previous transactions. It is included in block 100. Within block 100, it is the sixth transaction in the order in which it was received (since the index starts at 0).

[0042] Step 104, determining the business identifier of the business according to the business identifier of each historical business recorded in the account data, and acquiring data required for consensus based on the business identifier of each historical business executed by the account recorded in the account data, so as to determine the information to be agreed upon of the business.

[0043] In one or more embodiments of the present specification, after the blockchain node obtains the account data, since the account data contains the index of all the businesses that have been agreed upon by the account, for different business types, the blockchain node can further determine the data required for the consensus of the business to be executed based on the business identifiers of each historical business executed by the account recorded in the account data. In addition, the business identifier of the business to be executed can also be determined so that the account data can be updated after the subsequent consensus is passed.

[0044] Specifically, if the business to be executed specifies a historical business when it is initiated, then in step 100, the business data may also include a business identifier of the historical business. The blockchain node can determine the block number and business index of the historical business from the account data based on the business identifier of the historical business, and obtain the business data of the historical business through the block number and business index, and determine the data required for consensus based on business needs.

[0045] Alternatively, if the pending business does not specify a historical business when it is initiated, the pending business is executed based on the current state of the account. The blockchain node can determine the state of the account after the most recent business execution based on the business identifier of each historical business in the account data, as the current state of the account, to determine the data required for consensus.

[0046] Of course, in general, the blockchain node needs to verify whether the business to be executed is abnormal based on the data obtained from the account data. If it is abnormal, the subsequent steps will not be executed, that is, no more broadcasting for consensus. If it is determined that there is no abnormality, the subsequent steps can be continued for consensus. Since this process is already a relatively mature technology in the blockchain, this manual will not go into details.

[0047] Similarly, of course, the business data of the business to be executed is also the data required for consensus. The blockchain node can ultimately determine the data required for consensus based on the partial data determined from the account data and the business data of the business to be executed, and this specification does not make specific restrictions on this.

[0048] It should be noted that the above only discloses the process of obtaining the data required for consensus during the execution of two types of services. However, for different types of services, the data obtained may be different. However, in general, the data required for consensus usually includes at least part of the account data of the account in addition to the business data carried when the service is initiated. Therefore, by determining the account data, the blockchain node can obtain the data required for consensus. This specification does not limit or elaborate on which specific business types there are or which data needs to be obtained. This does not affect the data storage process of this specification, nor does it affect the normal execution of the service.

[0049] In addition, the blockchain node can also determine the business identifier (nonce) of the business to be executed. Specifically, the blockchain node can determine a data set for storing the business identifier from the account data. The data set is Figure 2 The content shown in includes each business identifier, and the block number and business index corresponding to each business identifier.

[0050] The blockchain node can then determine the business identifier of each historical business executed by the account based on the data set.

[0051] Finally, the service identifiers of the services are continuously accumulated and determined in the order of the determined service identifiers.

[0052] For example, taking the transaction business as an example, when a user initiates a new transaction, a nonce value needs to be specified. This value is equal to the nonce of the last transaction that was successfully included in the blockchain for the account before plus 1. If this is the first transaction issued by the account, the nonce is 0, if it is the second, the nonce is 1, and so on. The nonce is used to confirm whether the transaction comes from the legal order of the account. That is, it checks whether the nonce of the transaction is equal to the maximum nonce currently known to the account + 1. If not, the transaction is considered invalid or duplicated, because this may mean that the transaction has been processed or there is an attempt to replay the attack. Of course, in general, the business identifier of the business can also be used to verify whether the business is abnormal, so the business identifier can also be used for consensus.

[0053] Step 106, in response to the consensus of the information to be agreed upon being passed, based on the account identifier and the business identifier of the business, a globally unique query identifier for querying the business is determined, and the account data is updated in the database.

[0054] In the embodiment of the present specification, after the blockchain node determines the data required for the above consensus and the business identifier of the business in step 104, it can broadcast the consensus-pending information of the business, and update the account data of the account after the consensus-pending information of the business is reached.

[0055] Specifically, this specification does not restrict the consensus mechanism, broadcast mechanism, etc. The blockchain system can choose existing mature solutions. For each blockchain node, when the information to be agreed upon by the business passes the consensus, the blockchain node needs to update the account data. It should be noted that the account data updated at this time is not the blockchain ledger maintained by each blockchain node, but the Merkle tree of the global state stored in the database.

[0056] First, the blockchain node can determine the newly created block during consensus, and then determine the block identifier of the newly created block.

[0057] Afterwards, based on the location of the service in the newly created block, a service index of the service is determined.

[0058] Finally, the query identifier is used as an index to query the business data of the business, and the query identifier, the block number of the newly created block, and the business index are written into the account data of the account in the database. Figure 2Taking the account model shown in the figure as an example, the blockchain node needs to write: nonce: n+1, block: X, index: Y in the data set of the account data.

[0059] In summary, in the technical solution provided in this specification, the query identifier of all historical businesses is recorded in the account data corresponding to each account. The query identifier is composed of the account identifier + business identifier of the account. Therefore, the account data can be quickly queried through the account identifier, and the business data can be directly located on the blockchain from the account data through the business identifier. And when using the database engine to store these data, since the business identifiers are generated sequentially and are continuous values, using sequentially increasing serial numbers as indexes means that the newly inserted data is always located at one end of the key space, that is, the latest part. This can minimize the jumps between key-value pairs and reduce the probability of triggering Compaction. And in high-concurrency business scenarios, since most insertion operations are concentrated in the same area, Compaction can merge data more effectively, reduce the number of unnecessary merges, and thus save resources. From the root, a continuous key space makes it easier to arrange data in order, reduces fragmentation, and improves storage utilization.

[0060] Furthermore, since in the technical solution provided in this specification, the index of the business is no longer the hash value corresponding to the business data, in order to improve business security, the blockchain node can also determine the hash value of the business data and store it locally in the database so that secondary verification can be performed through the stored hash value when verification is required.

[0061] Specifically, in the embodiments of the present specification, in response to the consensus of the information to be agreed upon being passed, the blockchain node can perform a hash calculation on the business data of the business through a preset hash function to determine the hash value of the business. Afterwards, an association relationship between the query identifier and the hash value is constructed and stored. Moreover, since the hash value is associated with a regular query identifier at this time, the query identifier can be used as an index to establish a data structure to store these hash values. Alternatively, since the key-value pair is a query identifier-hash value structure, the hash value can also be stored as part of the account data in the global state tree. Whether the hash value is stored separately or in the Melk tree structure is not limited in this specification and can be set as needed.

[0062] Furthermore, after the hash value corresponding to each business is stored, when verification is needed, after verifying that the business is normal by querying the identification, business sequence, etc., a second verification can be performed based on the stored hash value.

[0063] Specifically, in response to a verification request for the business, the blockchain node may obtain the business data of the account, wherein the verification request carries a query identifier.

[0064] The blockchain node can then determine the hash value associated with the query identifier based on the association relationship stored in the above process and based on the query identifier.

[0065] Finally, according to the preset hash function, the obtained business data is hashed to determine the hash value to be verified. It is determined whether the hash value associated with the query identifier is consistent with the hash value just calculated. If they are consistent, it is determined that the verification has passed and the business can continue to be executed. If they are inconsistent, it is determined that the verification has not passed and there is a problem with the business data.

[0066] Optionally, in the technical solution provided in this specification, the index of the business data is a query identifier. Therefore, in one or more embodiments of this specification, when the blockchain node receives a query request, it no longer needs to consider the search for the hash value, but only needs to determine the query result based on the query identifier.

[0067] Specifically, when receiving a query request for business data, the blockchain node can obtain the corresponding business storage address from the account data according to the account ID and business ID, and then determine the block and location of the business data from the blockchain to obtain the business data. This process does not require a search solution indexed by hash values, so the search cost is low and the efficiency is high. It can improve the retrieval efficiency of business data for historical businesses in the blockchain.

[0068] First, the blockchain node responds to the business query request and determines that the business query request carries a query identifier, which is composed of an account identifier and a business identifier.

[0069] Afterwards, based on the account identifier, the account data corresponding to the account identifier is obtained from the global state tree in the form of a Melk tree stored in the database. Figure 2 Account data shown.

[0070] Then, according to the business identifier contained in the query identifier, the block number and business index of the business data corresponding to the business query request on the blockchain are determined from the account data. That is, according to the nonce, the block value and index value in the account data are determined.

[0071] Finally, according to the determined block number and business index, the business data is obtained from the blockchain. After the block value and index value are determined, how to obtain the business data is already the basic content in the field of blockchain technology, and this manual will not go into details.

[0072] From the above process, it can be seen that since the query identifier is based on the account identifier and the sequentially generated nonce, the query based on the business identifier often follows the sequential access mode, which allows the database to use the pre-fetch mechanism to load the data blocks that may be used later in advance, significantly improving the reading efficiency. In addition, the sequential access mode improves the utilization of the page cache, because continuous data is more likely to be cached, reducing disk I / O operations. For ordered data, building and maintaining indexes is simpler and more efficient. For example, structures such as B+ trees are very suitable for processing this type of query. It can effectively improve the efficiency of query retrieval and avoid the query process becoming a performance bottleneck of the blockchain system.

[0073] In summary, in the technical solution provided in this specification, the blockchain node in the blockchain system constructs a query identifier with an account identifier and a business identifier of each business as a globally unique identifier for querying the business. When the account data is stored in the local database of the node, not only the number of transactions of the account is stored, but the query identifier of each business executed by the account and the storage address of each business on the blockchain are stored, so that when updating the database, there is no need to consider a series of problems caused by the hash value constructed by a pure random number. It is equivalent to providing a new account model of blockchain accounts, in which not only the information of the most recent business indexed by a random number is stored, but the information of each business is recorded with an account identifier and a business identifier recorded in sequence. The database used to store account data in the blockchain node is more in line with the optimization mechanism of the existing high-performance database, and the query efficiency is effectively guaranteed. Even if the account data of a large number of accounts needs to be recorded, the database will not generate a large amount of data consumption due to the random number index. The performance of the database of the blockchain node can be effectively improved and the operating cost can be reduced.

[0074] Figure 3 is a schematic diagram of the structure of an electronic device in an exemplary embodiment. Figure 3 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other required hardware. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a device for storing business data at the logical level. Of course, in addition to the software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0075] Corresponding to the embodiment of the business data storage method in the aforementioned blockchain system, this specification also provides an embodiment of a business data storage device in the blockchain system.

[0076] Please refer to Figure 4 , the device is applied to a blockchain node in the blockchain system; the device may include:

[0077] Receiving module 401, the blockchain node obtains the business data of the business to be executed and the account identifier for executing the business;

[0078] An acquisition module 402 acquires account data corresponding to the account identifier from a database;

[0079] The determination module 403 determines the business identifier of the business according to the business identifier of each historical business recorded in the account data, and obtains data required for consensus based on the business identifier of each historical business executed by the account recorded in the account data, so as to determine the information to be agreed upon of the business;

[0080] The storage module 404, in response to the consensus on the information to be agreed upon being passed, determines a globally unique query identifier for querying the service based on the account identifier and the service identifier of the service, and updates the account data in the database.

[0081] Optionally, the acquisition module 402 is used to determine a leaf node of the account data of the account identifier from a Merkle tree of the global state stored in the database; and acquire the account data from the database through the leaf node.

[0082] Optionally, the determination module 403 is used to determine a data set for storing business identifiers from the account data; determine business identifiers of various historical businesses executed by the account based on the data set; and continue to accumulate and determine business identifiers of the businesses in the order of the determined business identifiers.

[0083] Optionally, the storage module 404 determines the block identifier of the newly created block; determines the business index of the business based on the position of the business in the newly created block; uses the query identifier as an index for querying the business data of the business, and writes the query identifier, the block number of the newly created block and the business index into the account data of the account in the database.

[0084] Optionally, the device also includes a query module 405, which is used to perform hash calculation on the business data of the business through a preset hash function in response to the consensus of the information to be agreed upon being passed, and determine the hash value of the business; construct an association relationship between the query identifier and the hash value, and store it.

[0085] Optionally, the query module 405 is used to obtain the business data of the account in response to a verification request for the business, the verification request carrying a query identifier; determine a hash value associated with the query identifier based on a stored association relationship; and verify the obtained business data based on the associated hash value.

[0086] Optionally, the query module 405 is used to respond to a business query request, determine that the business query request carries a query identifier, and the query identifier is composed of an account identifier and a business identifier; obtain account data corresponding to the account identifier from a database; determine, from the account data, based on the business identifier, a block number and a business index of the business data corresponding to the business query request on the blockchain; and obtain business data from the blockchain based on the determined block number and business index.

[0087] Optionally, the account data includes a query identifier of each historical business executed by the account, a location of the business content of each historical business on the blockchain, and an association between the query identifier of each historical business and the location on the blockchain.

[0088] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0089] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing processor executable instructions; wherein the processor implements the steps of the method described in any of the above embodiments by running the executable instructions.

[0090] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0091] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

Claims

1. A method for storing business data in a blockchain system, comprising: The blockchain node obtains the business data of the business to be executed and the account identifier for executing the business; Acquire account data corresponding to the account identifier from a database; Determine the business identifier of the business according to the business identifier of each historical business recorded in the account data, and obtain the data required for consensus based on the business identifier of each historical business executed by the account recorded in the account data, so as to determine the information to be agreed upon of the business; In response to the consensus on the information to be agreed upon being passed, a globally unique query identifier for querying the service is determined based on the account identifier and the service identifier of the service, and the account data is updated in the database.

2. According to the method of claim 1, obtaining the account data corresponding to the account identifier from the database comprises: Determine a leaf node of the account data of the account identifier from a Merkle tree of the global state stored in the database; The account data is obtained from the database through the leaf node.

3. The method according to claim 1, and determining the business identifier of the business according to the business identifier of each historical business recorded in the account data, comprising: Determining a data set for storing a service identifier from the account data; Determining, based on the data set, a business identifier of each historical business executed by the account; The service identifiers of the services are continuously determined by accumulating them in the order of the determined service identifiers.

4. The method according to claim 1, updating the account data in the database, comprises: Determine the block ID of the newly created block; Determine a service index of the service based on the location of the service in the newly created block; The query identifier is used as an index for querying the business data of the business, and the query identifier, the block number of the newly created block and the business index are written into the account data of the account in the database.

5. The method according to claim 1, further comprising: In response to the consensus of the information to be agreed upon being passed, performing hash calculation on the business data of the business through a preset hash function to determine a hash value of the business; An association relationship between the query identifier and the hash value is constructed and stored.

6. The method according to claim 5, further comprising: In response to a verification request for the business, obtaining business data of the account, wherein the verification request carries a query identifier; Determining a hash value associated with the query identifier according to the stored association relationship; The acquired business data is verified according to the associated hash value.

7. The method according to claim 1, further comprising: In response to the service query request, determining that the service query request carries a query identifier, where the query identifier consists of an account identifier and a service identifier; Acquire account data corresponding to the account identifier from a database; According to the business identifier, determine from the account data the block number and business index of the business data corresponding to the business query request on the blockchain; According to the determined block number and business index, business data is obtained from the blockchain.

8. According to any one of the methods described in claims 1-7, the account data includes a query identifier for each historical business executed by the account, the location of the business content of each historical business on the blockchain, and an association between the query identifier of each historical business and the location on the blockchain.

9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any one of the methods of claims 1 to 8 when executing the program.

10. A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

11. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

Images