Service data storage in blockchain system

Abstract

Provided in the present description is a service data storage method in a blockchain system. The method comprises: a blockchain node acquiring service data of a service to be executed, and an account identifier for executing said service; acquiring, from a database, account data corresponding to the account identifier; determining a service identifier of said service on the basis of service identifiers of historical services recorded in the account data, and acquiring data required for consensus on the basis of the service identifiers of the historical services executed by an account recorded in the account data, so as to determine information pending consensus of said service; and in response to a consensus of said information being reached, on the basis of the account identifier and the service identifier of said service, determining a globally unique query identifier for querying said service, and updating the account data in the database.

Description

Business Data Storage in Blockchain System Technical Field

[0001] This specification relates to the field of blockchain technology, and particularly 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 chain-like data structure in a sequential connection manner according to time sequence, and a distributed ledger that is tamper-proof and non-forgeable is guaranteed by cryptographic means. Due to the characteristics of blockchain such as decentralization, information immutability, and autonomy, blockchain has received increasing attention and applications.

[0003] In the prior art, when two business parties in a blockchain system conduct 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 consistency for other businesses based on this business data, the corresponding transaction content can be obtained by parsing the block number.

[0004] However, since 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 likely to occur during the process of storing and using business data. For example, in a database using the RocksDB engine, the compaction mechanism that originally reduces fragmented files and reclaims space to improve storage efficiency continuously generates a large number of small SSTable files as new business Hashes in small batches are continuously written into the database, and the burden of compaction will also increase accordingly. Moreover, the business Hash value is randomly generated data, and each write creates a new key-value pair instead of overwriting existing records, 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 a first aspect of the embodiments of this specification, a method for storing business data in a blockchain system is provided, comprising: a blockchain node acquiring business data of a business to be executed, and an account identifier for executing the business; acquiring account data corresponding to the account identifier from a database; determining a business identifier for the business based on the business identifiers of each historical business recorded in the account data, and acquiring consensus-required data based on the business identifiers of each historical business executed by the account recorded in the account data, to determine consensus-pending information for the business; and, in response to consensus being passed on the consensus-pending information, determining a globally unique query identifier for querying the business based on the account identifier and the business identifier of the business, and updating the account data in the database.

[0009] According to a second aspect of the embodiments of this specification, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in the first aspect.

[0010] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method as described in the first aspect.

[0011] According to a fourth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0012] In the technical solution provided in this specification, blockchain nodes within the blockchain system construct query identifiers using account identifiers and business identifiers for each business transaction. These query identifiers serve as globally unique identifiers for querying that business transaction. Therefore, when storing account data in the local database of this node, it not only stores the number of transactions for the account, but also the query identifiers for each business transaction executed by the account, as well as the storage address of each business transaction on the blockchain. This eliminates the need to consider the issues arising from hash values ​​constructed using purely random numbers when updating the database. This essentially provides a novel account model for blockchain accounts. This model not only stores information about the most recent transaction indexed by random numbers, but also records information for each business transaction using the account identifier and sequentially recorded business identifiers. This makes the database used to store account data in the blockchain node more compatible with the optimization mechanisms of existing high-performance databases, and effectively guarantees query efficiency. Even when recording a large amount of account data, the database will not incur excessive data consumption due to random number indexing. This can effectively improve the performance of the blockchain node's database and reduce operating costs. Attached Figure Description

[0013] Figure 1 is a flowchart illustrating an exemplary embodiment of a business data storage method in a blockchain system.

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

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

[0016] Figure 4 is a schematic diagram of the structure of a business data storage device in a blockchain system, as shown in an exemplary embodiment of this specification. Detailed Implementation

[0017] Currently, in blockchain systems employing the Account Model, account state information is stored in the blockchain's Global State Tree. This state tree is typically a Merkle Patricia tree, which organizes all accounts and their related information into an efficient data structure. Its root hash is recorded in the header of each block, ensuring the immutability and integrity of the state. The Global State Tree contains information about all accounts, including but not limited to: account balance, transaction count, storage root, and code hash. The account balance represents the amount of cryptocurrency held by the account. The transaction count indicates the number of transactions sent for Externally Owned Accounts (EOAs), and for contract accounts, it indicates the number of subcontracts created. The storage root points to another Merkle Patricia tree used to store the state variables within the contract account. The code hash is generally the hash value of the smart contract code and is only valid for the contract account.

[0018] Whenever a business transaction is executed, if that transaction changes the state of an account (e.g., transferring funds, calling a contract function), the corresponding node is updated in the state tree. To maintain consistency, a new state tree root hash is calculated after each state change and recorded in the header of the new block.

[0019] Generally, to improve blockchain performance, blockchain nodes typically maintain a complete copy of the state locally for rapid response to query requests. These nodes synchronize the latest blocks and update their local state in real time. Lightweight clients, such as wallet clients, do not store all historical data or state, but rely on trust assumptions and other mechanisms to obtain necessary state information. They primarily focus on block headers and proofs on specific paths to verify the state of certain accounts. Additionally, blockchain systems may also include archive nodes. These nodes not only store the current state but also retain snapshots of all historical states, which is crucial for applications that need access to older states, such as browser tools or auditing services.

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

[0021] However, to improve data storage performance, existing blockchain nodes typically introduce high-performance database engines. However, existing account models store data indexed by the hash value of the business transaction. As described in the background section, this presents a series of performance and cost issues. To address these problems, this specification provides a method for storing business data in a blockchain system.

[0022] Specifically, in database engines like RocksDB, the compaction mechanism is a crucial operation for maintaining data structures. It reduces disk space usage and optimizes read / 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 blockchain systems that use business hash values ​​as business indexes or identifiers, these hash values ​​are generated through cryptographic hashing of business content, making them almost entirely random. This means that each time a new record is inserted, key-value pairs are scattered throughout the key space, resulting in non-contiguous business relationships within the database's key space. Due to the randomness of these hash values, new key-value pairs are unlikely to be adjacent to existing data, causing each new insertion to trigger small-scale compactions. Over time, these frequent small-scale compactions accumulate into large-scale compaction events. Ultimately, a large number of compactions not only increase I / O load but can also lead to excessive consumption of CPU and memory resources, impacting overall system performance. While frequent compaction helps keep data compact, it can also lead to temporary disk space waste due to the failure to clean up old versions in a timely manner. Furthermore, excessive compaction activity can impact database response time and throughput, especially under high-concurrency write conditions.

[0023] On the other hand, hash values ​​are random numbers. Therefore, even after compaction optimization, business data for the same account is still distributed across different SSTables. This necessitates scanning multiple files when searching for a specific transaction, increasing lookup time. Furthermore, random access reduces the effectiveness of page caching because each query may involve data from different regions, reducing cache hit rate and further slowing down queries. Moreover, to accelerate random queries, additional indexes are typically needed, which introduces further storage and maintenance costs. These issues all stem from the account model using business hash values ​​as indexes or business identifiers, demonstrating a more significant impact on blockchain system performance in scenarios with high concurrency and large transaction volumes.

[0024] Furthermore, the blockchain system described in this manual uses blockchain nodes to store business data as an example. In reality, light clients select data storage methods and typically do not have the aforementioned issues. Archive nodes are not required; they can also store data using the methods provided in this manual, with the process being identical to that of blockchain nodes. This manual will not repeat the details here. In other words, all historical state snapshots are stored using the methods provided in this manual.

[0025] Based on this, this specification proposes a business data storage scheme suitable for blockchain systems, which will be described in detail below with reference to the accompanying drawings.

[0026] Figure 1 is a flowchart illustrating an exemplary embodiment of a business data storage method in a blockchain system. As shown in Figure 1, the method may include the following steps.

[0027] Step 100: The blockchain node obtains the business data of the business to be executed, as well as the account identifier for executing the business.

[0028] In one or more embodiments of this specification, any blockchain node in the blockchain system can act as the subject executing the business, obtaining the business to be executed and its business data. The business data of the business to be executed must contain at least the account identifiers of both parties involved in the business. For simplicity, this specification will use the account identifier of the account initiating the business as an example in subsequent explanations. It should be noted that if other accounts executing the business also have account data to store, the same process can be performed to determine and store the business data that needs to be stored.

[0029] Specifically, this blockchain node can obtain business data for the transaction to be executed. This business data includes at least the account identifiers of the transaction initiator and the recipient. The account identifier typically refers to an account address, a unique identifier used to distinguish different accounts. This address is usually a cryptographic hash value, ensuring uniqueness and immutability. The business data may also include the content of the transaction to be executed. Taking a transfer transaction as an example, the content to be executed could be the amount to be transferred or the address of the smart contract to be triggered. Of course, all of the above content needs to include the initiator's signature to ensure the validity of the business data.

[0030] Of course, since consensus in a blockchain requires business data—that is, determining the account status upon which the business is executed—the blockchain node also needs to determine the business identifier for that business. In this specification, this business identifier can specifically be a business sequence number (nonce). The business identifier can be used to indicate how many transactions a particular account has sent. Using a "transaction counter" or "transaction sequence number" clearly conveys that the nonce is an incrementing value used to ensure that transactions are executed in sequence and to prevent replay attacks. Therefore, the blockchain node needs to obtain account data through the account identifier to determine the business identifier.

[0031] Step 102: Obtain the account data corresponding to the account identifier from the database.

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

[0033] Specifically, the blockchain node can determine the storage address of the account data for the account identifier from the global state tree stored in its local database. Typically, this global state tree is a data structure used in the blockchain to store the current state of all accounts, usually in the form of a Merkle Patricia Trie (MPT), an optimized trie suitable for efficient key-value pair lookups. Of course, the blockchain node in this specification is a fully functional node, therefore it stores the Merkle tree locally.

[0034] The blockchain node can traverse downwards from the Merkle tree root node based on the account identifier. At each step, the next branch is determined based on a part of the account identifier, until a leaf node is reached. When a leaf node is reached, the node stores the specific state information associated with the account identifier, i.e., account data, including information such as balance, nonce, and contract code.

[0035] After determining the leaf node corresponding to the account, the account data for that account, updated most recently, can be retrieved from the database. In this specification, the account model for this account data is shown in Figure 2.

[0036] As shown in Figure 2, this account model contains the dataset required for storage services. This dataset includes the business identifiers of the account from the first service to the services executed after the most recent consensus. Each business identifier corresponds to the block number where the business data is located, as well as the business index within that block. This account data not only contains the business identifier and corresponding block number and index of the most recent service, but also includes all the data corresponding to the services of the account that have passed consensus. Furthermore, the unique identifier of each service is no longer based on a hash value determined from the business data. Therefore, when storing the Merkle tree, the database can avoid storing a large number of random numbers, i.e., it does not need to store a large number of hash values ​​corresponding to services. When querying services, a specific service for a specific account can be determined based on the account identifier + business identifier. This reduces the complexity of database data storage while ensuring that services can be executed normally. At the same time, compared to querying random numbers, querying using the account identifier + business identifier method can also significantly improve database query speed.

[0037] [Corrected according to Rule 91, 05.12.2025] For example, suppose an account has a transaction with a nonce of 3 and a corresponding block number of block 100, with a transaction index of index 5. This means that because the nonce is 3, this transaction comes from an account that has already sent three previous transactions. It is included in block number 100. Within block 100, it is the sixth transaction in the order of receipt (since the index starts from 0).

[0038] Step 104: Determine the business identifier of the business based on the business identifiers of each historical business recorded in the account data, and obtain the consensus-required data based on the business identifiers of each historical business executed by the account recorded in the account data, so as to determine the consensus-pending information of the business.

[0039] In one or more embodiments of this specification, after obtaining account data, the blockchain node, because the account data package contains an index of all services for which the account has reached consensus, can further determine the data required for consensus on the service to be executed based on the service identifiers of the historical services executed by the account recorded in the account data, for different service types. Furthermore, it can also determine the service identifier of the service to be executed so that the account data can be updated after subsequent consensus is reached.

[0040] [Corrected according to Rule 91 05.12.2025] Specifically, if the business to be executed specifies a historical business when it is initiated, then in step 100, the business data may also contain the business identifier of the historical business. Then the blockchain node can determine the block number and business index of the historical business from the account data according to 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 the business needs.

[0041] Alternatively, if no historical business is specified when the pending business is initiated, the pending business is executed based on the current state of the account. In this case, 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, and use this as the current state of the account to determine the data required for consensus.

[0042] Of course, under normal circumstances, the blockchain node needs to verify whether the business to be executed is abnormal based on the data obtained from the account data. If an abnormality is found, subsequent steps will not be executed, that is, the broadcast will not be conducted for consensus. If it is determined that there is no abnormality, subsequent steps can continue to conduct consensus. Since this process is a relatively mature technology in blockchain, this manual will not elaborate on it further.

[0043] Similarly, the business data of the transaction to be executed is also the data required for consensus. The blockchain node can ultimately determine the data required for consensus based on partial data determined from the account data and the business data of the transaction to be executed; this specification does not impose specific limitations on this.

[0044] 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 business operations. However, the data obtained may differ for different types of business. Generally speaking, the data required for consensus, in addition to the business data carried at the time of business initiation, usually includes at least a portion of the account data. Therefore, by determining the account data, the blockchain node can obtain the data required for consensus. This specification does not limit or elaborate on what other business types or what data needs to be obtained, and this does not affect the data storage process described in this specification, nor does it affect the normal execution of the business.

[0045] In addition, the blockchain node can also determine the nonce of the service to be executed. Specifically, the blockchain node can determine the dataset used to store the nonce from the account data. This dataset, as shown in Figure 2, contains each nonce, as well as the block number and service index corresponding to each nonce.

[0046] The blockchain node can then determine the business identifier of each historical business performed by the account based on the dataset.

[0047] Finally, following the order of the determined business identifiers, the business identifiers of the aforementioned business are further accumulated and determined.

[0048] For example, in a transaction process, when a user initiates a new transaction, they need to specify a nonce value. This value is equal to the nonce of the last transaction successfully included in the blockchain for that account, plus 1. If this is the account's first transaction, the nonce is 0; if it's the second, the nonce is 1, and so on. The nonce is used to confirm whether the transaction comes from the account's legitimate order. That is, it checks whether the transaction's nonce is equal to the account's currently known maximum nonce plus 1. If not, the transaction is considered invalid or a duplicate, as this may mean the transaction has already been processed or there is a replay attack attempt. Of course, in general, this business identifier can also be used to verify whether the business is abnormal, so it can also be used for consensus.

[0049] Step 106: In response to the consensus being passed on the pending consensus information, based on the account identifier and the business identifier of the business, determine a globally unique query identifier for querying the business, and update the account data in the database.

[0050] In the embodiments of this specification, after the blockchain node determines the data required for the consensus and the business identifier of the business in step 104, it can broadcast the consensus information of the business, and update the account data of the account after the consensus information of the business passes the consensus.

[0051] Specifically, this specification does not impose restrictions on consensus mechanisms, broadcast mechanisms, etc.; the blockchain system can choose existing mature solutions. For each blockchain node, once the consensus information for that business transaction is reached, the blockchain node needs to update the account data. It should be noted that the updated account data at this time is not the blockchain ledger maintained by each blockchain node, but rather a Merkle tree of the global state stored in the database.

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

[0053] Then, based on the location of the service in the newly created block, the service index is determined.

[0054] Finally, using the query identifier as an index for querying the business data of the business, 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. Taking the account model shown in Figure 2 as an example, the blockchain node needs to write the following into the database of the account data: nonce: n+1, block: X, index: Y.

[0055] In summary, the technical solution provided in this specification records query identifiers for all historical transactions within the account data corresponding to each account. These query identifiers are composed of the account identifier and the transaction identifier. Therefore, account data can be quickly retrieved using the account identifier, while the transaction identifier allows direct location of transaction data on the blockchain from the account data. Furthermore, when storing this data using a database engine, since the transaction identifiers are generated sequentially and are continuous values, using sequentially increasing sequence numbers as indexes means that newly inserted data is always located at one end of the key space, i.e., the latest part. This minimizes jumps between key-value pairs and reduces the probability of triggering compaction. In high-concurrency scenarios, when most insertion operations are concentrated in the same area, compaction can more effectively merge data, reducing unnecessary merging and thus saving resources. Fundamentally, a contiguous key space makes it easier to arrange data sequentially, reducing fragmentation and improving storage utilization.

[0056] Furthermore, since the index of the business is no longer the hash value corresponding to the business data in the technical solution provided in this specification, 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.

[0057] Specifically, in the embodiments of this specification, in response to the consensus being passed on the information to be agreed upon, the blockchain node can perform hash calculation on the business data of the business using a preset hash function to determine the hash value of the business. Then, the association between the query identifier and the hash value is constructed and stored. Furthermore, since the hash value is now associated with a regular query identifier, the query identifier can be used as an index to build 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 a Melk tree structure is not limited in this specification and can be set as needed.

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

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

[0060] Then, the blockchain node can determine the hash value associated with the query identifier based on the association stored in the above process and the query identifier.

[0061] Finally, based on a preset hash function, the acquired business data is hashed to determine the hash value to be verified. It is then compared to the hash value associated with the query identifier. If they match, the verification is successful, and the business process can continue. If they do not match, the verification fails, and there is a problem with the business data.

[0062] Optionally, in the technical solutions provided in this specification, the index of business data is a query identifier. Therefore, in one or more embodiments of this specification, when the blockchain node receives a query request, it does not need to consider searching for hash values, but only needs to determine the query result based on the query identifier.

[0063] Specifically, upon receiving a query request for business data, the blockchain node can retrieve the corresponding business storage address from the account data based on the account identifier and business identifier, and then determine the block and location of the business data within the blockchain to obtain the data. This process does not require a hash-indexed search scheme, thus resulting in low search costs and high efficiency. This improves the efficiency of retrieving historical business data from the blockchain.

[0064] First, in response to a business query request, the blockchain node determines that the business query request carries a query identifier, which consists of an account identifier and a business identifier.

[0065] Next, based on the account identifier, the account data corresponding to the account identifier is retrieved from the global state tree in the form of a Melk tree stored in the database. The account data is shown in Figure 2.

[0066] Then, based on 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, the block value and index value in the account data are determined based on the nonce.

[0067] Finally, based on the determined block number and business index, the business data is retrieved from the blockchain. After determining the block value and index value, the specific method for retrieving the business data is fundamental to blockchain technology and will not be elaborated upon in this document.

[0068] [Corrected from Rule 91, 05.12.2025] As seen in the above process, since the query identifier is constructed based on the account identifier and the nonce generated sequentially, queries based on the business identifier often follow a sequential access pattern. This allows the database to utilize a prefetching mechanism to preload data blocks that may be used later, significantly improving read efficiency. Furthermore, the sequential access pattern improves the utilization of the page cache, as consecutive 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 like B+ trees are very suitable for handling this type of query. This effectively improves query retrieval efficiency and prevents the query process from becoming a performance bottleneck in the blockchain system.

[0069] In summary, the technical solution provided in this specification involves blockchain nodes within a blockchain system constructing query identifiers using account identifiers and business identifiers for each business transaction. These query identifiers serve as globally unique identifiers for querying that business. Therefore, when storing account data in the local database of this node, it stores not only the number of transactions for each account, but also the query identifiers for each business transaction executed by that account, as well as the storage address of each business transaction on the blockchain. This eliminates the need to consider the issues arising from hash values ​​constructed using purely random numbers when updating the database. This effectively provides a novel account model for blockchain accounts. This model not only stores information about the most recent transaction indexed by random numbers, but also records information for each business transaction using account identifiers and sequentially recorded business identifiers. This makes the database used to store account data in the blockchain node more compatible with the optimization mechanisms of existing high-performance databases, and effectively guarantees query efficiency. Even when recording a large amount of account data, the database will not incur excessive data consumption due to random number indexing. This effectively improves the performance of the blockchain node's database and reduces operating costs.

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

[0071] Corresponding to the aforementioned embodiments of the business data storage method in the blockchain system, this specification also provides embodiments of the business data storage device in the blockchain system.

[0072] Please refer to Figure 4. This device is applied to a blockchain node in the blockchain system. The device may include: a receiving module 401, which acquires business data of a business to be executed and an account identifier for executing the business; an acquisition module 402, which acquires account data corresponding to the account identifier from a database; a determining module 403, which determines the business identifier of the business based on the business identifiers of each historical business recorded in the account data, and acquires consensus-required data based on the business identifiers of each historical business executed by the account recorded in the account data, so as to determine the consensus information of the business; and a storage module 404, which, in response to the consensus of the consensus information, determines a globally unique query identifier for querying the business based on the account identifier and the business identifier of the business, and updates the account data in the database.

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

[0074] Optionally, the determining module 403 is configured to determine a dataset for storing business identifiers from the account data; determine the business identifiers for each historical business performed by the account based on the dataset; and continue to accumulate and determine the business identifiers of the business according to the order of the determined business identifiers.

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

[0076] Optionally, the device further includes a query module 405, which, in response to the consensus of the pending consensus information being passed, performs hash calculation on the business data of the business using a preset hash function to determine the hash value of the business; constructs the association between the query identifier and the hash value, and stores it.

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

[0078] Optionally, the query module 405 is configured to respond to a business query request by determining that the business query request carries a query identifier, the query identifier being composed of an account identifier and a business identifier; obtaining account data corresponding to the account identifier from the database; determining, based on the business identifier, the block number and business index of the business data corresponding to the business query request on the blockchain from the account data; and obtaining the business data from the blockchain based on the determined block number and business index.

[0079] Optionally, the account data includes a query identifier for each historical transaction performed by the account, the location of the transaction content of each historical transaction on the blockchain, and the association between the query identifier of each historical transaction and its location on the blockchain.

[0080] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

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

[0082] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0083] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

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, as well as the account identifier for executing the business; Retrieve the account data corresponding to the account identifier from the database; Based on the business identifiers of each historical business recorded in the account data, the business identifier of the business is determined, and based on the business identifiers of each historical business executed by the account recorded in the account data, the data required for consensus is obtained to determine the consensus information of the business. In response to the consensus being passed on the pending consensus information, a globally unique query identifier for querying the service is determined based on the account identifier and the service identifier, and the account data is updated in the database.

2. The method according to claim 1, wherein obtaining account data corresponding to the account identifier from the database includes: From the Merkle tree of the global state stored in the database, determine the leaf node of the account data for the account identifier; The account data is retrieved from the database through the leaf nodes.

3. The method according to claim 1, wherein the business identifier of the business is determined based on the business identifiers of each historical business recorded in the account data, includes: From the account data, determine the dataset used to store the business identifier; Based on the dataset, determine the business identifiers for each historical transaction performed by the account; The business identifiers of the determined business identifiers are then accumulated and determined in the order they are determined.

4. The method according to claim 1, wherein updating the account data in the database comprises: Determine the block identifier for the new block; Based on the location of the service in the newly created block, determine the service index of the service; Using the query identifier as an index for querying the business data of the business, 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 being reached on the pending consensus information, the business data of the business is hashed using a preset hash function to determine the hash value of the business. Construct and store the association between the query identifier and the hash value.

6. The method according to claim 5, further comprising: In response to a verification request for the service, the service data of the account is obtained, wherein the verification request carries a query identifier; Based on the stored associations, determine the hash value associated with the query identifier; The acquired business data is verified based on the associated hash value.

7. The method according to claim 1, further comprising: In response to a business query request, it is determined that the business query request carries a query identifier, which consists of an account identifier and a business identifier; Retrieve the account data corresponding to the account identifier from the database; Based on the business 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; Based on the determined block number and business index, business data is obtained from the blockchain.

8. The method according to any one of claims 1-7, wherein the account data includes a query identifier for each historical transaction performed by the account, the location of the business content of each historical transaction on the blockchain, and the association between the query identifier of each historical transaction and its 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, when executing the program, implements the steps of the method as claimed in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the steps of the method as claimed in any one of claims 1-8.

11. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-8.

Images