Blockchain-based data processing method, apparatus, device, and readable storage medium

Abstract

The application discloses a blockchain-based data processing method, device and equipment and a readable storage medium. The method comprises the following steps: a first node sends a data query request for target transaction state data to a state database; the state database is a database used for uniformly storing state data of each block in a blockchain; a data query result returned by the state database based on the data query request is received; if the data query result is a query result in which the target transaction state data is not contained in the state database, a data write request for the target transaction state data is sent to the state database; and the data write request is used for requesting to write the target transaction state data into the state database. According to the application, the data redundancy can be reduced and the storage space consumption can be reduced in the storage service of the blockchain.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, device, and readable storage medium based on blockchain. Background Technology

[0002] Blockchain is a novel application model of computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is primarily used to organize data chronologically and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also enables data verification, storage, and updating. Blockchain can also perform encrypted data transmission, node identification, and secure access, making it an advanced distributed infrastructure. Currently, due to its immutability and authenticity, blockchain applications are increasingly prevalent.

[0003] In blockchain technology, when storing on-chain data, each blockchain node continuously synchronizes its data, ensuring that the block data stored by each node is identical. For example, regarding the transaction status data of each block in the blockchain, each blockchain node synchronously pulls the same transaction status data and stores it locally. This leads to excessive data redundancy, meaning that each blockchain node stores consistent data, undoubtedly resulting in a significant waste of storage space and excessive storage costs. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, and readable storage medium based on blockchain, which can reduce data redundancy and storage space consumption in blockchain storage operations.

[0005] One embodiment of this application provides a blockchain-based data processing method, including:

[0006] The first node sends a data query request for the target transaction status data to the state database; the target transaction status data refers to the status data of the transaction data contained in the target block; the state database is a database used to uniformly store the status data of each block in the blockchain; the first node belongs to the blockchain;

[0007] Receive the data query results returned by the status database based on the data query request;

[0008] If the data query result is a query result that does not contain the target transaction status data in the status database, a data write request for the target transaction status data is sent to the status database. The data write request is used to request that the target transaction status data be written to the status database. The target transaction status data in the status database has a shared access attribute. The target transaction status data with the shared access attribute is used for the first node and the second node to share and access the data. The second node belongs to the blockchain.

[0009] One embodiment of this application provides a blockchain-based data processing device, including:

[0010] The query request sending module is used to send data query requests for target transaction status data to the status database; target transaction status data refers to the status data of transaction data contained in the target block; the status database is a database used to uniformly store the status data of each block in the blockchain; the first node belongs to the blockchain;

[0011] The result receiving module is used to receive the data query results returned by the status database based on the data query request;

[0012] The write request sending module is used to send a data write request for the target transaction status data to the status database if the data query result is a query result that does not contain the target transaction status data in the status database. The data write request is used to request the status database to write the target transaction status data into the status database. The target transaction status data in the status database has a shared access attribute. The target transaction status data with the shared access attribute is used for the first node and the second node to share and access the data. The second node belongs to the blockchain.

[0013] In one embodiment, the blockchain-based data processing device may further include:

[0014] The verification module is used to verify the consistency of the target transaction status data based on the existence proof if the data query result contains the existence proof, and obtain the verification result.

[0015] The local write module is used to write the target transaction status data to the local database of the first node if the verification result is a verification failure.

[0016] The attribute determination module is used to determine the write attribute of the target transaction status data as a written attribute if the verification result is a verification pass result.

[0017] In one embodiment, the proof of existence includes a target Merkle root for the target transaction state data of the target block;

[0018] The verification module may include:

[0019] The hash acquisition unit is used to obtain the existing state hash value corresponding to the existing block; the existing block refers to the block in the blockchain whose block height is less than the target block, and the write attribute of the transaction state data of the existing block is the written attribute;

[0020] The generation unit is used to obtain the target state hash value of the target transaction state data, and generate the Merkle root to be matched for the target transaction state data based on the existing state hash value and the target state hash value.

[0021] The matching unit is used to match the Merkle root to be matched with the target Merkle root;

[0022] The result determination unit is used to determine the verification result as a verification pass result if the Merkle root to be matched is the same as the target Merkle root;

[0023] The result determination unit is also used to determine the verification result as a verification failure result if the Merkle root to be matched is different from the target Merkle root.

[0024] In one embodiment, the write request sending module may include:

[0025] The block information acquisition unit is used to acquire the transaction identifier of the transaction data contained in the target block, as well as the block height of the target block;

[0026] The version number determination unit is used to use the block height of the target block and the transaction identifier as the data version number of the target transaction status data;

[0027] The request generation unit is used to establish a mapping relationship between the data version number and the target transaction status data, and generate a data write request containing the target transaction status data and the mapping relationship.

[0028] The write request sending unit is used to send a data write request containing target transaction status data and mapping relationship to the status database, determine that it is a data write request for the target transaction status data.

[0029] In one embodiment, the blockchain-based data processing device may further include:

[0030] The receiving module is used to receive the data writing results returned by the status database based on the data writing request;

[0031] The read request sending module is used to send a data read request carrying a data version number to the status database when the read time for the target transaction status data is reached if the data write result is a successful write result. The data read request is used to request to read the target transaction status data. The read time is later than the write time. The write time refers to the time when the first node successfully writes the target transaction status data to the status database.

[0032] The status detection module is used to receive the data reading results returned by the status database based on the data reading request, and to perform storage status detection on the target transaction status data based on the data reading results.

[0033] In one embodiment, the state detection module may include:

[0034] The first state determination unit is used to determine the storage state of the target transaction state data as normal if the data reading result is a reading result carrying the target transaction state data.

[0035] The second state determination unit is used to determine the storage state of the target transaction state data as abnormal if the data reading result is a reading result that does not contain the target transaction state data in the state database. The abnormal state is used to indicate that the state database has moved the target transaction state data out of the state database based on the storage limit value of the state database.

[0036] In one embodiment, the state detection module may further include:

[0037] The local write unit is used to write the target transaction status data to the local database of the first node if the storage status of the target transaction status data is abnormal.

[0038] In one embodiment, at the time of reading, the block height of the target block is the maximum block height in the local block height set corresponding to the first node; the local block height set is a set consisting of the block heights corresponding to N local blocks stored in the local database of the first node, and the N local blocks include the target block; N is a positive integer;

[0039] The status detection module may also include:

[0040] The node marking unit is used to mark the first node as a synchronization lag node when the storage state of the target transaction state data is in an abnormal state; when executing the consensus business of the block to be consensus, the voting information of the synchronization lag node for the consensus business is invalid voting information; the block generation time of the block to be consensus is later than the block generation time of the target block.

[0041] In one embodiment, the blockchain-based data processing device may further include:

[0042] The traversal module is used to traverse the set of existing state data stored in the local database of the first node when the time for reading the target transaction state data is reached; the set of existing state data contains one or more existing state data stored in the local database.

[0043] The step execution module is used to execute the step of sending a data read request carrying a data version number to the status database if the target transaction status data is not found in one or more existing status data stored in the local database.

[0044] In one embodiment, the moment when the first node sends a data query request to the state database is the first moment; the time period in which the target transaction state data is contained in the state database is the time period composed of the second moment and the third moment. The second moment is the moment when the second node writes the target transaction state data into the state database, and the third moment is the moment when the state database moves the target transaction state data out of the state database based on the storage limit of the state database; the first moment and the third moment are both later than the second moment, and the third moment is earlier than the first moment; the second node belongs to the blockchain.

[0045] In one embodiment, the blockchain-based data processing device may further include:

[0046] The prompt receiving module is used to receive duplicate write prompt information returned by the status database based on the data write request; the duplicate write prompt information is used to indicate that the target transaction status data is duplicate write data for the status database;

[0047] The local status writing module is used to write the target transaction status data to the local database of the first node based on the repeated write prompt information.

[0048] In one embodiment, the blockchain-based data processing device may further include:

[0049] The lagging node marking module is used to mark the first node as a synchronous lagging node based on the repeated write prompt information; when executing the consensus business of the block to be consensused, the voting information of the synchronous lagging node for the consensus business is invalid voting information; the block generation time of the block to be consensused is later than the block generation time of the target block.

[0050] One embodiment of this application provides a computer device, including: a processor and a memory;

[0051] The memory stores a computer program, which, when executed by a processor, causes the processor to perform the methods described in the embodiments of this application.

[0052] One aspect of this application provides a computer-readable storage medium storing a computer program, which includes program instructions. When executed by a processor, the program instructions perform the methods described in this application.

[0053] One aspect of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the method provided in one aspect of the embodiments of this application.

[0054] In this embodiment, a unified state database is used to store the transaction state data of different nodes (such as the first node and the second node) in the blockchain. Each node can write the transaction state data of its local block into the state database. To reduce duplicate writes, each node can send a data query request to the state database before writing the transaction state data of a certain block. If the state database does not contain the transaction state data, the node can write the transaction state data into the state database. The transaction state data stored in the state database has a shared access attribute, and all nodes in the blockchain can share and access it. It should be understood that by using a unified state database to store the transaction state data of different nodes, the transaction state data of each node can be stored in a unified location, thereby improving the situation where the data stored locally by each node is consistent, reducing data redundancy, and thus reducing the overall storage space consumption of the blockchain. In summary, this application can reduce data redundancy and reduce storage space consumption in blockchain storage operations. Attached Figure Description

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

[0056] Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application;

[0057] Figure 2 This is a schematic diagram of a data storage architecture provided in an embodiment of this application;

[0058] Figure 3 This is a flowchart of a data processing method based on blockchain provided in an embodiment of this application;

[0059] Figure 4 This is a flowchart illustrating another blockchain-based data processing method provided in an embodiment of this application;

[0060] Figure 5 This is a schematic diagram of an incremental Merkle tree structure provided in an embodiment of this application;

[0061] Figure 6 This is a schematic diagram of a process for detecting the storage status of transaction status data according to an embodiment of this application;

[0062] Figure 7 This is a system logic flowchart of writing transaction status data to a status database provided in an embodiment of this application;

[0063] Figure 8 This is a system logic flowchart for reading transaction status data from a status database, provided in an embodiment of this application.

[0064] Figure 9 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application;

[0065] Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0066] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0067] The blockchain-based data processing method provided in this application can be applied to blockchain networks. A blockchain network comprises a network of nodes that record and query data blocks on the blockchain. Each node in the blockchain network is a blockchain node, which is a computer device capable of querying or recording data blocks. Since the solutions provided in this application involve blockchain and related technologies, for ease of understanding, the following will prioritize the explanation of blockchain and related concepts.

[0068] 1. Blockchain: In a narrow sense, blockchain is a chain-like data structure with blocks as the basic unit. Blocks use digital digests to verify previously obtained transaction history, making it suitable for the tamper-proof and scalable requirements of distributed ledger scenarios. In a broader sense, blockchain also refers to the distributed ledger technology implemented using the blockchain structure, including distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocols, and smart contracts. The goal of blockchain is to implement a distributed data record ledger that only allows additions, not deletions. The underlying basic structure of the ledger is a linear linked list. The linked list consists of a series of "blocks," with each subsequent block recording the hash value of the previous block. The validity of each block (and the transactions within it) can be quickly verified by calculating the hash value. If a node in the network proposes to add a new block, the block must be confirmed through a consensus mechanism.

[0069] It should be understood that blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is primarily used to organize data chronologically and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Essentially, blockchain is a decentralized database where each node stores the same blockchain. The blockchain network distinguishes nodes into core nodes, data nodes, and light nodes. Core nodes are responsible for the consensus of the entire blockchain network; in other words, core nodes are the consensus nodes in the blockchain network. The process of writing transaction data into the ledger in a blockchain network can be as follows: a client sends transaction data to a data node or light node, and then the transaction data is relayed among the data nodes or light nodes in the blockchain network until the consensus node receives the transaction data. The consensus node then packages the transaction data into a block and reaches a consensus with other consensus nodes. After the consensus is passed, the block carrying the transaction data is written into the ledger.

[0070] It is understood that a blockchain system can include smart contracts. A smart contract in the blockchain system can be understood and executed by all nodes (including consensus nodes), capable of executing arbitrary logic and obtaining results. Users can initiate a transaction request through a client, invoking a smart contract already deployed on the blockchain. Subsequently, data nodes or light nodes on the blockchain can send the transaction request to the consensus nodes, and each consensus node can run the smart contract. It should be understood that a blockchain can include one or more smart contracts, which can be distinguished by an identity document (ID) or name. The transaction request initiated by the client can also carry the smart contract's identity document or name, thus specifying the smart contract that the blockchain needs to run. If the smart contract specified by the client requires reading data, each consensus node will access its local ledger to read the data. Finally, each consensus node will verify whether the execution results are consistent (i.e., reach consensus). If they are consistent, the execution result can be stored in its respective local ledger and returned to the client.

[0071] 2. Blockchain Nodes: Blockchain networks divide nodes into consensus nodes (also known as core nodes) and synchronization nodes (which can include data nodes and light nodes). Consensus nodes are responsible for the consensus process across the entire blockchain network; synchronization nodes are responsible for synchronizing the ledger information of the consensus nodes, i.e., synchronizing the latest block data. Both consensus and synchronization nodes include network communication components in their internal structure, because a blockchain network is essentially a peer-to-peer (P2P) network, requiring communication with other nodes in the blockchain network through P2P components. Resources and services in the blockchain network are distributed across various nodes; information transmission and service implementation occur directly between nodes, without the need for intermediaries or centralized servers (third parties).

[0072] 3. Public Key and Private Key: A public key and a private key are a key pair (one public key and one private key) obtained through an algorithm. The public key is the publicly known part of the key pair, while the private key is the private key. Public keys are typically used for encrypting data, verifying digital signatures, etc. This algorithm ensures that the resulting key pair is unique. When using this key pair, if data is encrypted with one key, it must be decrypted with the other key. For example, data encrypted with the public key must be decrypted with the private key, and vice versa; otherwise, decryption will fail.

[0073] 4. Hash Value: Also known as an information feature value or characteristic value, a hash value is generated by converting input data of arbitrary length into cryptographic data and producing a fixed output using a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way cryptographic function. In a blockchain, each block (except the initial block) contains the hash value of its predecessor block, which is called the parent block of the current block. The hash value is a core and crucial aspect of blockchain technology, preserving the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0074] 5. Smart Contract: A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. In a blockchain system, a smart contract (or simply contract) is code that all nodes on the blockchain can understand and execute, capable of performing arbitrary logic and producing results. In practical applications, smart contracts are managed and tested through transactions on the blockchain. Each transaction is equivalent to a Remote Procedure Call (RPC) request to the blockchain system. If a smart contract is like an executable program, the blockchain is like the operating system that provides the runtime environment. A blockchain can contain multiple contracts, distinguished by contract identity (ID), identifier, or name. For example, a smart contract may contain a governance consensus committee contract, which is mainly used to manage consensus nodes and may include recording the node status of consensus nodes, dynamically adding consensus nodes, and removing abnormal consensus nodes.

[0075] 6. A wallet is used to provide the function of trading digital assets, including initiating transactions (that is, sending the transaction record of the current transaction to other nodes in the blockchain system; after other nodes verify the transaction successfully, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining digital assets (or digital resources) in the digital asset address (also known as the digital resource address).

[0076] Please see Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application. For example... Figure 1As shown, the system may include a blockchain network 100a, an application server 100b, and a cluster of terminal devices. The blockchain network 100a may include blockchain nodes 10a, 10b, 10c, and 10d. It is understood that the blockchain network 100a may include one or more blockchain nodes, and this embodiment does not limit the number of blockchain nodes. It is understood that in the blockchain network 100a, blockchain nodes 10a, 10b, and 10d can all interact with data through a network connection with blockchain node 10c. It should be understood that each blockchain node in the blockchain network 100a (e.g., blockchain nodes 10a, 10b, 10c, and 10d) can be used to maintain the same blockchain (e.g., ...). Figure 1 The blockchain 10e shown in the diagram allows any two blockchain nodes in the blockchain network 100a to form a peer-to-peer (P2P) network. This P2P network can use a P2P protocol, which is an application layer protocol running on top of the Transmission Control Protocol (TCP). In a distributed system, any device, such as a server or terminal device, can join and become a blockchain node.

[0077] Among them, it is understandable that, such as Figure 1 The blockchain nodes 10a, 10b, 10c, and 10d shown can each have a one-to-one correspondence with the corresponding roles (i.e., entity objects in the corresponding business scenarios) in the blockchain network 100a that need to be accessed. These business scenarios can specifically include electronic invoice scenarios, social scenarios, resource issuance scenarios, and payment scenarios. Specifically, the business data information in the corresponding business scenarios can include electronic invoice information in the electronic invoice scenario, data interaction information in the social scenario, resource issuance information in the resource issuance scenario, and asset transfer records in the payment scenario. The specific content of the business data information in each corresponding business scenario will not be listed here.

[0078] It is understood that the above system may include one or more application servers; the number of application servers will not be limited here. Figure 1 The application server 100b shown can connect to the blockchain network 100a to facilitate data interaction via the network connection. The application server 100b can be a backend server for an application that has business functions related to processing data in the blockchain network 100a.

[0079] The terminal device cluster may include terminal devices 100c, 100d, 100e, ..., 100f. It is understood that the terminal device cluster may include one or more terminal devices, and this application embodiment does not limit the number of terminal devices. Network connections may exist between terminal devices in the cluster; for example, there is a network connection between terminal devices 100c and 100d. Simultaneously, any terminal device in the cluster may have a network connection to application server 100b; for example, there is a network connection between terminal device 100f and application server 100b. Furthermore, any terminal device in the cluster may have a network connection to blockchain network 100a; for example, there is a network connection between terminal device 100d and blockchain network 100a. Also, any terminal device in the cluster may have a network connection to storage device 200a; for example, there is a network connection between terminal device 100f and storage device 200a. The above network connections are not limited in method; they can be established directly or indirectly via wired networks, wireless networks, or other methods. This application does not impose any limitations on this.

[0080] It should be understood that, such as Figure 1 Each terminal device in the terminal cluster shown can have an application client (also referred to as a target application) installed. The application server 100b can be the backend server corresponding to the application client. When the application client runs on each terminal device, it can interact with the aforementioned... Figure 1 The application servers 100b shown interact with each other via the network connection described above. The application client (target application) can be a data processing application client, such as a video application, live streaming application, social application, instant messaging application, game application, music application, shopping application, novel application, browser, digital asset application, or digital resource application. This application client can be a standalone client or an embedded sub-client integrated into another client (e.g., a social client, an educational client, or a multimedia client), without limitation. Taking a social application as an example, application server 100b can be a collection of multiple servers, including a backend server and a data processing server corresponding to the social application. Therefore, each terminal device can transmit data with application server 100b through the application client corresponding to the social application. For example, each terminal device can upload relevant business data requests to application server 100b through the application client of the social application, and then application server 100b can distribute the relevant business data requests to other terminal devices or transmit them to the blockchain network 100a.

[0081] It is understood that in the specific implementation of this application, data such as user information are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0082] For ease of subsequent understanding and explanation, the embodiments of this application may be... Figure 1 In the terminal cluster shown, a terminal device is selected as the target terminal device, for example, terminal device 100c. The target terminal device can send transaction data to a data node or a light node. The transaction data is then passed between data nodes or light nodes in the blockchain network in a relay manner until the consensus node receives the transaction data. The consensus node then packages the transaction data into a block and conducts consensus with other consensus nodes. After the consensus is passed, the block carrying the transaction data is written into the ledger.

[0083] It should be understood that after each block passes consensus, each consensus node stores the block's state data in its local database. To reduce data redundancy and storage space consumption, this application provides a blockchain-based data processing method: a unified state database to store state data from different nodes. Each node can write the transaction state data of its local block into the state database. To reduce duplicate writes, before writing the transaction state data of a block, each node can send a data query request to the state database. If the state database does not contain the transaction state data, the node can then write it. The transaction state data stored in the state database has a shared access attribute, allowing all nodes in the blockchain to access it. Therefore, each node no longer needs to store consistent state data, reducing data redundancy and thus lowering storage space consumption.

[0084] For ease of understanding, let's take the example of a consensus node (e.g., the first node) receiving a block (e.g., the target block). The first node wants to store the transaction state data of the target block (which can refer to the state data of the transactions contained in the target block, referred to as the target transaction state data). The first node can then send a data query request for the target transaction state data to the state database. Subsequently, the state database can iterate through the database based on this query request to check if the target transaction state data exists and return a query result to the first node. If the query result indicates that the target transaction state data is not present in the state database, the first node can send a data write request for the target transaction state data to the state database. Upon receiving this write request, the state database can write the target transaction state data to the database. However, if the query result indicates that the target transaction state data is already present in the state database, there is no need to rewrite the target transaction state data.

[0085] As described above, the method provided in this application embodiment can be executed by a computer device, which includes, but is not limited to, terminal devices, application servers, or blockchain nodes. The application server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal devices can include, but are not limited to, smart terminals with multimedia data processing functions (e.g., video data playback functions, music data playback functions), such as smartphones, tablets, laptops, desktop computers, smart TVs, smart speakers, desktop computers, smartwatches, and in-vehicle devices, but are not limited to these.

[0086] It is understandable that the aforementioned application server 100b, terminal device 100c, terminal device 100d, terminal device 100e..., and terminal device 100f can all be blockchain nodes in the blockchain network 100a. In a distributed system like blockchain, any form of computer device, such as application servers, terminal devices, or other electronic devices, can become a node in the blockchain system by joining the peer-to-peer network.

[0087] To facilitate understanding of the blockchain data storage method provided in this application, please also refer to... Figure 2 , Figure 2 This is a schematic diagram of a data storage architecture provided in an embodiment of this application. For example... Figure 2As shown, the data storage architecture of this application may include at least a blockchain network 200 and a unified state database 2000. The blockchain network 200 in this embodiment may include different blockchain nodes, for example, such as... Figure 2 As shown, it can specifically include blockchain nodes 200a, 200b, 200c, ..., 200m; the state database in this embodiment can include a single-machine database, a distributed database, and a cloud database, etc. Figure 2 As shown, taking the state database as an example of a distributed database, the state database 2000 can be composed of three database nodes. Among them, database node 2000a can be the primary database node, and database nodes 2000b and 2000c can be standby database nodes.

[0088] It is understandable that after consensus is reached and a block is generated, each blockchain node in the blockchain network 2000 can obtain the transaction status data of the transaction data involved in the block. This transaction status data refers to the status data of the execution result after the transaction is executed. For example, taking the transaction data as account A transferring 10 yuan to account B, if account A originally had a balance of 10 yuan and account B originally had a balance of 10 yuan, then after the transaction is executed, account A's balance will become 0 yuan, and account B's balance will become 20 yuan. The new balances of account A and account B respectively can be used as the status data of this transaction data; that is, "account A's balance is 0 yuan, and account B's balance is 20 yuan" is the transaction status data of this transaction data. It should be understood that after obtaining the transaction status data of the block, the blockchain node can write this transaction status data to the status database 2000 to persist the transaction status data. Similarly, if a blockchain node needs to read certain status data, it can also read it from the status database 2000. For the specific implementation methods of reading status data from the status database and writing status data to the status database, please refer to the following sections. Figure 3 The description in the corresponding embodiments.

[0089] It should be noted that, in order to reduce the occurrence of blockchain nodes repeatedly writing state data to the state database 2000, before a blockchain node writes the state data of a certain transaction to the state database 2000, the blockchain node can first send a query request to the state database to check whether the transaction state data of the current block has already been written to the state database (there may be cases where other blockchain nodes have already written the transaction state data to the state database). If it has already been written, the blockchain node does not need to send another write request to the state database for the transaction state data. This can reduce the data write latency and improve the speed at which blockchain nodes process blocks, indirectly improving the system throughput.

[0090] It is understandable that, compared to each blockchain node having its own database to store consistent transaction state data, the embodiments of this application can effectively reduce the total storage space consumption of state data in the entire blockchain network. To facilitate understanding of the beneficial effects of this application, examples will be provided below. Taking a blockchain network with n nodes, k copies (i.e., redundancy) of data in the state database (typically, n is much larger than k), and w storage space occupied by state data in a single blockchain node as an example, when each blockchain node has its own database to store consistent transaction state data, the storage space occupied by the state data of all nodes in the blockchain network is nw; while if the unified state database provided by this application is used to store consistent state data, the occupied storage space is kw. Therefore, the proportion of storage space consumption reduced by the solution provided by this application can be calculated as (nw-kw) / nw (i.e., 1-k / n). It is evident that the embodiments of this application can effectively reduce data redundancy and state data storage consumption, and the larger the scale of nodes in the blockchain network, the greater the reduction in storage overhead that this application can achieve.

[0091] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The method can be implemented using blockchain nodes (e.g., the aforementioned...). Figure 1 The core node in the corresponding embodiment can be executed, or it can be executed by blockchain nodes and terminal devices (e.g., the one mentioned above). Figure 1 The method is jointly executed by the terminal devices in the corresponding embodiments. The following explanation will use the execution of this method by a blockchain node as an example. Figure 3 As shown, the blockchain-based data processing method may include at least the following steps S101-S103:

[0092] Step S101: The first node sends a data query request for the target transaction status data to the state database; the target transaction status data refers to the status data of the transaction data contained in the target block; the state database is a database used to uniformly store the status data of each block in the blockchain; the first node belongs to the blockchain.

[0093] In this application, both the first node and the second node can be core nodes (also known as consensus nodes) in the blockchain. Core nodes can receive transaction data sent from data nodes or light nodes in the blockchain. This transaction data can be sent by a terminal device to a data node or light node. Specifically, this transaction data can be data generated by the terminal device based on a user-initiated transaction. After obtaining user authorization, the terminal device can send this transaction data to a data node or light node. When a core node receives transaction data from different data nodes, it can temporarily cache the received transaction data in a transaction pool. After receiving transaction data from data nodes over a period of time, the core node can retrieve one or more transaction data from the transaction pool and generate a block based on this transaction data. If the node generating the block wishes to store it in the blockchain, it needs to initiate a consensus request for the block to the consensus nodes in the blockchain. The consensus nodes in the blockchain can then reach a consensus on the block based on this consensus request. After the block passes consensus, it can be stored in the blockchain.

[0094] To reduce data redundancy and storage space consumption in the blockchain system, this application provides a remote state database to uniformly store transaction state data from different nodes. Transaction state data refers to the state data of transactions involved in a specific block, and more specifically, the execution result state data of the transaction data. For example, taking the transaction data of account A transferring 10 yuan to account B as an example, if account A originally had a balance of 10 yuan and account B originally had a balance of 10 yuan, after the transaction is executed, account A's balance will become 0 yuan, and account B's balance will become 20 yuan. The new balances of account A and account B can be used as the state data of this transaction data; that is, "account A's balance is 0 yuan, and account B's balance is 20 yuan" is the transaction state data of this transaction data.

[0095] In other words, this application provides a database for uniformly storing the state data of each block in a blockchain. This database can be called a state database, which can refer to any database with data storage capabilities. For example, a state database can include a single-machine database, a distributed database, and a cloud database, etc. For the state data of transaction data involved in a certain block (such as a target block), if a blockchain node (such as the first node) wishes to store it, the first node can write it to the state database (i.e., store it in the state database). Since each blockchain node synchronizes blocks and each blockchain node does not interfere with each other when storing data, when the first node wishes to store the target transaction state data, the target transaction state data may have already been written to the state database by other blockchain nodes. Therefore, to reduce the situation of duplicate data writing, before the first node writes the target transaction state data to the state database, the first node can pre-initiate a data query request for the target transaction state data to check whether the target transaction state data already exists in the state database. If the target transaction state data does not exist in the state database, the first node can then write the target transaction state data to the state database.

[0096] Optionally, and understandably, to facilitate differentiation of various transaction status data, this application may configure a unique version number for each transaction status data to uniquely identify it. This version number can be composed of the block height of the block containing the transaction data and the transaction identifier of the transaction data. The transaction identifier can refer to information used to identify the transaction data within that block, specifically the transaction number of the transaction data within that block. For example, for a given transaction data, if the block height of the block containing the transaction data is 35, and the transaction data is the 4th data item in that block, then the transaction number of the transaction data is 4, and the version number of the transaction data can be <35, 4>. When each node writes each transaction status data to the status database, it can also send the version number of the transaction status data to the status database, which can then associate and store the transaction status data with the version number. Similarly, when each node sends a data query request for a specific transaction state data to the state database, it can send the version number of that transaction state data to the state database. The state database can then use this version number to query whether a transaction state data associated with that version number already exists in the state database. Taking target transaction state data as an example, when the first node sends a data query request for the target transaction state data to the state database, it can obtain the block height of the target block in the blockchain (referred to as the target block height) and the transaction number of the transaction data to which the target transaction state data belongs in the target block (referred to as the target transaction number). Subsequently, the first node can use the target block height and the target transaction number to construct the version number of the target transaction state data (referred to as the target version number). The first node can then generate a data query request containing the target version number and send the data query request to the state database.

[0097] Step S102: Receive the data query results returned by the status database based on the data query request.

[0098] In this application, the state database can query the state database based on the aforementioned data query request to see if the target transaction state data exists. If it exists, the state database can return a proof of existence of the target transaction state data to the first node, so that the first node can verify whether the target transaction state data in the first node is consistent with the target transaction state data stored in the state database (that is, verify the consistency and reliability of the target transaction state data). The first node can perform corresponding subsequent processing based on the verification result (see the following for specific processing methods). Figure 4(The content described in the corresponding embodiment); if it does not exist, the state database can return a null value to the first node as a data query result. The null value can be used to indicate that the state database does not contain the target transaction state data.

[0099] Step S103: If the data query result is a query result in the status database that does not contain the target transaction status data, then a data write request for the target transaction status data is sent to the status database. The data write request is used to request that the target transaction status data be written to the status database. The target transaction status data in the status database has a shared access attribute. The target transaction status data with the shared access attribute is used for the first node and the second node to share and access the data. The second node belongs to the blockchain.

[0100] In this application, if the data query results do not contain the target transaction status data, the first node can send a data write request for the target transaction status data to the status database, requesting that the target transaction status data be written to the status database. It should be noted that after the target transaction status data is written to the status database, the query attribute of the target transaction status data will change to a shared access attribute, meaning that the target transaction status data can be shared and accessed by various nodes in the blockchain (such as the first node and the second node).

[0101] It should be understood that, as described above, when writing a certain transaction status data to the status database in this application embodiment, the version number of the transaction status data can also be associated and written to the status database at the same time, so as to better distinguish each transaction status data. The same applies to the target transaction status data; the version number of the target transaction status data can also be associated and written to the status database at the same time. Therefore, the data write request for the target transaction status data sent by the first node to the status database can carry the version number of the target transaction status data. Specifically, the implementation of the first node sending the data write request for the target transaction status data to the status database can be as follows: The first node can obtain the transaction identifier of the transaction data contained in the target block, and the block height of the target block; then, the block height of the target block and the transaction identifier can be used as the data version number of the target transaction status data; subsequently, a mapping relationship can be established between the data version number and the target transaction status data, and a data write request containing the target transaction status data and the mapping relationship can be generated; the data write request containing the target transaction status data and the mapping relationship can be determined as a data write request for the target transaction status data, and finally, the data write request for the target transaction status data can be sent to the status database.

[0102] Optionally, the transaction data continuously received in the blockchain may be based on the same account. For example, transaction data 1 is a transfer of 10 yuan from account a to account b, while transaction data 2 is a transfer of 20 yuan from account a to account c (transaction data 2 was generated later than transaction data 1). After executing transaction data 1 and transaction data 2, different transaction status data for account a will be obtained, while transaction data 2 is the latest status data for account a. That is to say, the status data corresponding to transaction data 1 is historical status data, which is no longer valid. If it continues to be stored in the status database, it will consume the storage space of the status database. In order to further improve the storage consumption of the status database, this application embodiment can configure a storage limit value for the status database to specify the maximum amount of transaction status data that the status database can store. When the transaction status data stored in the status database reaches the maximum storage amount, the status database can move the historical status data out of the status database in order of the storage time of the transaction status data (the time it was written to the status database) (for example, moving the historical status data out in order of storage time from earliest to latest).

[0103] Understandably, due to network latency, node anomalies, and other factors, the speed at which different blockchain nodes synchronize blocks may vary, and the latest block heights of each node may differ, resulting in inconsistent state data across nodes (they may lag behind or be ahead). Therefore, when a node synchronizes blocks too slowly, the transaction state data for the latest block corresponding to that node may have already been written to the state database by other nodes and removed from the state database based on its storage limit. Since the state database does not contain this transaction state data, the node can store it in its local database for later querying. For ease of understanding, let's take the example of a first node wanting to write target transaction status data to the state database. Assume the first node is a node with a slower block synchronization speed, and the second node has already written the target transaction status data to the state database in advance. If the moment when the first node sends a data query request for the target transaction status data to the state database is the first moment, and the time period containing the target transaction status data in the state database is the time period composed of the second moment and the third moment, the second moment can be the moment when the second node writes the target transaction status data to the state database, and the third moment can be the moment when the state database moves the target transaction status data out of the state database based on the storage limit of the state database (wherein, both the first moment and the third moment are later than the second moment, and the third moment is earlier than the first moment; like the first node, the second node also belongs to the blockchain). After the first node sends a data write request for the target transaction status data to the status database, since the target transaction status data has already been written, the status database can return a duplicate write prompt message for the target transaction status data to the first node (to indicate that the target transaction status data is duplicate data written to the status database). The first node can receive the duplicate write prompt message returned by the status database based on the data write request. Subsequently, the first node can determine that it has fallen too far behind based on the duplicate write prompt message, and then the first node can write the target transaction status data to the first node's local database for subsequent query use.

[0104] Optionally, and understandably, for blockchain nodes that lag too far behind, inaccurate consensus might occur due to insufficient data synchronization during consensus operations. Therefore, if a node is determined to be significantly behind in data synchronization, it can be identified as an abnormal node, and its voting information will be invalid when executing consensus operations for a particular block. Taking the first node as an example, based on the duplicate write warning returned by the state database, the first node can be marked as a lagging node. When executing consensus operations for subsequent blocks (blocks whose generation time is later than the target block's generation time, referred to as blocks awaiting consensus), the voting information of this lagging node for that consensus operation can be determined as invalid.

[0105] In this embodiment, a unified state database is used to store the transaction state data of different nodes (such as the first node and the second node) in the blockchain. Each node can write the transaction state data of its local block into the state database. To reduce duplicate writes, each node can send a data query request to the state database before writing the transaction state data of a certain block. If the state database does not contain the transaction state data, the node can write the transaction state data into the state database. The transaction state data stored in the state database has a shared access attribute, and all nodes in the blockchain can share and access it. It should be understood that by using a unified state database to store the transaction state data of different nodes, the transaction state data of each node can be stored in a unified location, thereby improving the situation where the data stored locally by each node is consistent, reducing data redundancy, and thus reducing the overall storage space consumption of the blockchain. In summary, this application can reduce data redundancy and reduce storage space consumption in blockchain storage operations.

[0106] Through the above Figure 3 As described in the corresponding embodiment, when the data query result returned by the state database to the first node does not contain the target transaction state data, the first node can send a data write request for the target transaction state data to the state database, requesting that the target transaction state data be written to the state database. However, if the data query result contains a proof of existence of the target transaction state data, the first node can verify the consistency of the target transaction state data stored in the state database based on the proof of existence, and perform corresponding processing based on the verification result. For details, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart illustrating another blockchain-based data processing method provided in this application embodiment. The process can correspond to the above-described... Figure 3In the corresponding embodiment, when the data query result contains an existence proof for the target transaction status data, the processing flow of the first node is as follows: (e.g.) Figure 4 As shown, the process may include at least the following steps S401-S404:

[0107] Step S401: If the data query result is a query result containing an existence proof, then the consistency of the target transaction state data is verified based on the existence proof to obtain the verification result.

[0108] For example, this application can determine the existence of state data at a specified block height using an existence proof. The existence proof can be constructed from an incremental Merkle tree. For clarity, please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram of an incremental Merkle tree structure provided in an embodiment of this application. For example... Figure 5 As shown, when a node (such as the first node) receives a block, it first performs a hash calculation on the read / write set (specifically, the transaction state data of the transaction data in the block) to obtain the hash value of the block. Then, it further constructs a new incremental Merkle root by combining this hash value with the incremental Merkle root hash (the total hash value of the transaction state data in the previous block) of the preceding block. This new incremental Merkle root then serves as the incremental Merkle root hash of the current block, and this process is repeated. Figure 5 Taking the incremental Merkle tree as an example, BH h LH can be used to represent the hash value of the read / write set in the h-th block (e.g., the hash value of the transaction state data in the h-th block). h This can be used to represent the total hash value of the Merkle tree root when the Merkle tree height is h (i.e., the root hash value of the incremental Merkle tree after writing block h). As can be seen, LH h =hash <LH h-1 BH h >, that is, LH h By LH h-1 and BH h It is calculated. Whenever a block arrives, the hash value of the block's transaction state data is calculated, and then hashed with the current root tree to build an incremental Merkle tree upwards. For example, the new root tree LH3 is obtained by calculating the hash of BH3 and LH2. It can be understood that the incremental Merkle tree can be stored in each node's local database, built based on local blocks, and used for verifying the correctness of existence proofs. At the same time, the incremental Merkle tree can also be stored in a unified state database, built based on the state data stored in the state database.

[0109] Understandably, when a node sends a request to the state database to query whether an LH of height h (i.e., block height) exists in the state database, h <h,LH h When querying the state database to see if a transaction state data of block height h exists, the state database can search for a node of height h in the incremental Merkle tree. If it does not exist, it means that transaction state data of that height has not yet been written to the state database, and the state database can return a null value. If it does exist, the state database can further determine whether LH of height h in the incremental Merkle tree is equal to LH. h and return the existence proof LH h And two child nodes, for example, such as Figure 5 (As shown in the proof of existence for block 3). Blockchain nodes can compare the proof of existence returned by the state database with the structure at a specified height corresponding to their local incremental Merkle tree structure to determine if the state data stored in the state database is consistent with the data to be written to the node. If they are consistent, no further writing is needed; otherwise, the node can write it to its local database. It should be understood that since the node also stores the incremental Merkle tree locally, the authenticity of the returned result can be verified through the returned proof of existence, thus preventing the state database from maliciously returning incorrect results. Furthermore, if the state data in the state database is inconsistent with the node's local state data, the state database cannot pass the LH (Legacy Integer) verification. h By constructing two child nodes to return an erroneous existence proof, the reliability of the data can be guaranteed.

[0110] In other words, as described above, for the existence proof returned by the state database to the first node, this existence proof can contain the Merkle root of the target transaction state data for the target block (that is, the hash value of the incremental Merkle root of the target transaction state data for the target block, which can be called the target Merkle root). In this case, the specific implementation method for the first node to verify the consistency of the target transaction state data based on this existence proof and obtain the verification result can be as follows: The existing state hash value corresponding to the existing block can be obtained; where the existing block can refer to a block in the blockchain with a block height less than the target block (which can be understood as the preceding block of the target block, specifically the previous block of the target block, and the existing state hash value of the existing block can specifically refer to the Merkle root of the previous block). The root (of the target transaction state data) has a write attribute for the existing block's transaction state data. Then, the target state hash value of the target transaction state data can be obtained. Based on the existing state hash value and the target state hash value, a Merkle root to be matched for the target transaction state data can be generated. The Merkle root to be matched can then be matched with the target Merkle root. If the Merkle root to be matched is the same as the target Merkle root, the verification result is determined as a successful verification result (meaning the target transaction state data on the first node's local machine is consistent with the target transaction state data stored in the state database). If the Merkle root to be matched is different from the target Merkle root, the verification result is determined as a failed verification result (meaning the target transaction state data on the first node's local machine is inconsistent with the target transaction state data stored in the state database).

[0111] Step S402: Determine whether the verification passed.

[0112] For example, if the verification passes, the corresponding verification result is a verification pass result; if the verification fails, the corresponding verification result is a verification fail result. When the verification passes, the subsequent step S404 can be executed; when the verification fails, the subsequent step S403 can be executed.

[0113] Step S403: If the verification result is a verification failure, the target transaction status data is written to the local database of the first node.

[0114] For example, if the verification result is a verification failure, it can be determined that the two data are inconsistent. Then, the first node can write the target transaction status data into the first node's local database. In subsequent queries, the target transaction status data is also read from the local database.

[0115] Step S404: If the verification result is a successful verification result, then the write attribute of the target transaction status data is determined as a written attribute.

[0116] For example, when the verification result is a verification pass result, it can be determined that the two data are consistent. In this case, the first node does not need to write the target transaction status data into the status database again. At this time, the first node can determine the write attribute of the target transaction status data as a written attribute.

[0117] In this embodiment, a unified state database is used to store the transaction state data of different nodes (such as the first node and the second node) in the blockchain. Each node can write the transaction state data of its local block into the state database. To reduce duplicate writes, each node can send a data query request to the state database before writing the transaction state data of a certain block. If the state database does not contain the transaction state data, the node can write the transaction state data into the state database. The transaction state data stored in the state database has a shared access attribute, and all nodes in the blockchain can share and access it. It should be understood that by using a unified state database to store the transaction state data of different nodes, the transaction state data of each node can be stored in a unified location, thereby improving the situation where the data stored locally by each node is consistent, reducing data redundancy, and thus reducing the overall storage space consumption of the blockchain. In summary, this application can reduce data redundancy and reduce storage space consumption in blockchain storage operations.

[0118] Furthermore, through the above Figure 3As can be seen from the corresponding embodiment, the state database can, based on the storage limit, sequentially remove historical state data from the state database according to the storage time order of each transaction state data. When a node needs to read a certain transaction state data, the node can send a read request for that transaction state data to the state database (at this time, it can carry the version number of the transaction state data). If the state database contains the transaction state data of that version, the state database can return the query result; if the state database does not contain the transaction state data of that version (the state database has removed the transaction state data of that version), the state database can return the corresponding information (such as a prompt message that the data has been removed) to the node. Then the node can reconstruct the transaction state data according to the local block and store the transaction state data in the local database for subsequent queries. Specifically, taking the example of the first node writing target transaction status data to the status database, after establishing a mapping relationship between the data version number and the target transaction status data, the first node can generate a data write request containing the target transaction status data and the mapping relationship, and send this data write request to the status database. The status database can then return a data write result to the first node (which may include a successful write result and a failed write result). The first node can then perform corresponding processing based on the data write result. For example, if the data write result is a failed write result, the first node can try writing again (or check the data format and then try to initiate the data write request again). If the data write result is a successful write result, the first node can, at a later time, initiate a read request for the target transaction status data to the status database to determine the storage status of the target transaction status data.

[0119] For ease of understanding, please refer to the following: Figure 6 , Figure 6 This is a schematic diagram illustrating a process for detecting the storage status of transaction status data, provided in an embodiment of this application. This process can refer to the above... Figure 3 In the corresponding embodiment, the subsequent process after the first node sends a data write request to the state database. For example... Figure 6 As shown, the process may include at least the following steps S601-S603:

[0120] Step S601: Receive the data write result returned by the status database based on the data write request.

[0121] For example, after establishing a mapping relationship between the data version number and the target transaction status data, the first node can generate a data write request containing the target transaction status data and the mapping relationship, and send the data write request to the status database. The status database can then return a data write result to the first node (which may include a successful write result and a failed write result).

[0122] Step S602: If the data writing result is a successful write result, then when the time for reading the target transaction status data is reached, a data read request carrying a data version number is sent to the status database; the data read request is used to request to read the target transaction status data; the read time is later than the write time, and the write time refers to the time when the first node successfully writes the target transaction status data to the status database.

[0123] For example, a successful write result indicates that the target transaction status data has been successfully written to the status database. The "reading time" for the target transaction status data can refer to the moment when the target transaction status data needs to be read (e.g., when executing a transaction, the target transaction status data needs to be read); it can also refer to the moment when the target transaction status data is checked. For instance, after the target transaction status data is successfully written to the status database, the first node can check the storage status of the target transaction status data after a certain period of time (e.g., after 3 seconds). Upon reaching the reading time for the target transaction status data, the first node can send a data read request to the status database carrying the version number of the target transaction status data (i.e., the aforementioned data version number).

[0124] Step S603: Receive the data reading result returned by the status database based on the data reading request, and perform storage status detection on the target transaction status data based on the data reading result.

[0125] For example, the state database can query whether the target transaction state data associated with the data version number exists in the state database based on the aforementioned data read request. If it exists, the state database can generate a data read result containing the target transaction state data and return the data read result to the first node; if it does not exist, the state database can return a null value (to indicate that the target transaction state data is not included in the state database). The first node can receive the data read result returned by the state database and perform storage status detection on the target transaction state data based on the data read result. Specifically, the implementation of the storage status detection on the target transaction state data based on the data read result can be as follows: if the data read result carries the target transaction state data, the storage status of the target transaction state data can be determined to be normal; if the data read result is a read result where the target transaction state data is not included in the state database, the storage status of the target transaction state data can be determined to be abnormal. The abnormal status indicates that the state database has removed the target transaction state data from the state database based on the state database's storage limit. In other words, if the data reading result is a result in the status database not containing the target transaction status data, it can be determined that the status database has moved the target transaction status data out of the status database based on the storage limit. At this time, the first node can determine the storage status of the target transaction status data as an abnormal state.

[0126] It is understandable that when the storage status of the aforementioned target transaction status data is in an abnormal state, the first node can write the target transaction status data to its local database for subsequent traceability and query.

[0127] Optionally, and understandably, as described above, nodes can store state data not stored in the state database into their local database. When a node needs to read a specific transaction state data, it can first check its local database to see if the data exists. If the data is not found in the local database, the node can then send a data read request to the state database. In other words, regarding the first node sending a data read request to the state database for the target transaction state data, at the time of reading the target transaction state data, the first node can first traverse the set of existing state data stored in its local database. This set of existing state data includes one or more existing state data items stored in the local database. If the target transaction state data is not found in the one or more existing state data items stored in the local database, then the node can execute the step of sending a data read request carrying a data version number to the state database.

[0128] Optionally, it is understandable that when the first node's synchronization speed is too slow, the blocks synchronized by the first node lag behind those of other nodes. If, at the time when the target transaction state data is read, the target block is still the latest block of the first node, then the first node is a lag node in synchronization, and can be marked as a lag node in synchronization. In other words, when the target transaction state data is read, if the block height of the target block is the largest block height in the local block height set corresponding to the first node (the local block height set is the set of N local blocks stored in the first node's local database, where N local blocks include the target block, and N is a positive integer), indicating that the target block is the latest synchronized block of the first node, then if the storage state of the target transaction state data is detected to be abnormal, it can be indicated that the target transaction state data under the target block is state data stored earlier in the state database. At this time, the state data of many other blocks has been stored, which can indicate that the first node is lagging behind in synchronization by a large number of blocks. For blockchain nodes that lag too far behind, there may be situations where the consensus is inaccurate due to insufficient data synchronization when executing consensus business. Therefore, when it is determined that the synchronization speed of a certain node is too far behind, the node can be identified as an abnormal node, and the voting information of the node is invalid when executing the consensus business of a certain block. Taking the first node as an example, the first node can be marked as a lagging node. When executing consensus services for subsequent blocks (blocks whose generation time is later than the generation time of the target block, which can be called blocks pending consensus), the voting information of the lagging node for the consensus service can be determined as invalid voting information.

[0129] In this embodiment, a unified state database is used to store the transaction state data of different nodes (such as the first node and the second node) in the blockchain. Each node can write the transaction state data of its local block into the state database. To reduce duplicate writes, each node can send a data query request to the state database before writing the transaction state data of a certain block. If the state database does not contain the transaction state data, the node can write the transaction state data into the state database. The transaction state data stored in the state database has a shared access attribute, and all nodes in the blockchain can share and access it. It should be understood that by using a unified state database to store the transaction state data of different nodes, the transaction state data of each node can be stored in a unified location, thereby improving the situation where the data stored locally by each node is consistent, reducing data redundancy, and thus reducing the overall storage space consumption of the blockchain. In summary, this application can reduce data redundancy and reduce storage space consumption in blockchain storage operations.

[0130] Furthermore, for ease of understanding, please refer to Figure 7 , Figure 7 This is a system logic flowchart for writing transaction status data to a status database, provided in an embodiment of this application. This process can be performed by blockchain nodes (e.g., the aforementioned...). Figure 1 The core node in the corresponding embodiment can be executed, or it can be executed by blockchain nodes and terminal devices (e.g., the one mentioned above). Figure 1 The method is jointly executed by the terminal devices in the corresponding embodiments. The following explanation will use the execution of this method by a blockchain node as an example. Figure 7 As shown, the process may include at least the following steps S71-S77:

[0131] Step S71: Obtain the block status data.

[0132] Specifically, the block status data here can refer to the transaction status data of the transactions involved in the block, such as the target transaction status data of the target block.

[0133] Step S72: Construct a local incremental Merkle tree.

[0134] Specifically, each blockchain node can build a local incremental Merkle tree, as detailed above. Figure 5 The content described in the corresponding embodiments will not be repeated here.

[0135] Step S73: Determine whether the status data has been written to the status database.

[0136] Specifically, each blockchain node can send a data query request to the state database to check whether the state data has been written to the state database. If it has been written, the subsequent step S75 can be executed; otherwise, the subsequent step S74 can be executed.

[0137] Step S74: Write the status data into the status database.

[0138] Step S75: Determine if the data is consistent.

[0139] Specifically, if the state data has been written to the state database and the state database contains the state data, the state database can return an existence proof. The blockchain node can then use this existence proof and its local incremental Merkle tree to verify the consistency of the state data. If the verification result indicates that the data is consistent, then step S77 can be executed; otherwise, step S76 can be executed.

[0140] Step S76: Write the status data to the local database.

[0141] Step S77: Determine that the status data has been written to the attribute.

[0142] For the specific implementation methods of steps S71-S77, please refer to the above. Figure 3 The description of writing the target transaction status data to the status database in the corresponding embodiments will not be repeated here.

[0143] It should be understood that by using a unified state database to store the transaction state data of different nodes, the transaction state data of each node can be stored in a unified location, thereby improving the situation where the data stored locally on each node is consistent, reducing data redundancy, and thus reducing the overall storage space consumption of the blockchain.

[0144] Furthermore, for ease of understanding, please refer to Figure 8 , Figure 8 This is a system logic flowchart for reading transaction status data from a status database, provided in an embodiment of this application. This process can be performed by blockchain nodes (e.g., the aforementioned...). Figure 1 The core node in the corresponding embodiment can be executed, or it can be executed by blockchain nodes and terminal devices (e.g., the one mentioned above). Figure 1 The method is jointly executed by the terminal devices in the corresponding embodiments. The following explanation will use the execution of this method by a blockchain node as an example. Figure 8 As shown, the process may include at least the following steps S81-S86:

[0145] Step S81: Obtain a read request for the status data.

[0146] Step S82: Determine whether the status data exists in the local database.

[0147] Specifically, when a blockchain node receives a read request for state data, it can first traverse the local database to check if the state data exists. If it exists, the subsequent step S83 can be executed, that is, the state data can be read directly from the local database. If it does not exist, the subsequent step S84 can be executed, that is, to determine whether the state data exists in the state database.

[0148] Step S83: Read the status data from the local database.

[0149] Step S84: Determine whether the state data exists in the state database.

[0150] Specifically, if the state data exists in the state database, the subsequent step S86 can be executed, that is, the state data can be read from the state database; if the state data does not exist in the state database, the subsequent step S85 can be executed.

[0151] Step S85: Reconstruct and save the state data based on the local block.

[0152] Specifically, if the state data does not exist in the state database, the blockchain node can reconstruct the state data based on the block data of its local block and store the state data in the local database.

[0153] Step S86: Read the status data from the status database.

[0154] It should be understood that by using a unified state database to store the transaction state data of different nodes, the transaction state data of each node can be stored in a unified location, thereby improving the situation where the data stored locally on each node is consistent, reducing data redundancy, and thus reducing the overall storage space consumption of the blockchain.

[0155] Further, please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. The blockchain-based data processing device can be a computer program (including program code) running on a computer device; for example, the blockchain-based data processing device is an application software. The blockchain-based data processing device can be used to execute... Figure 3 The method shown. (As illustrated) Figure 9 As shown, the blockchain-based data processing device 1 may include: a query request sending module 11, a result receiving module 12, and a write request sending module 13.

[0156] The query request sending module 11 is used to send a data query request for the target transaction status data to the status database; the target transaction status data refers to the status data of the transaction data contained in the target block; the status database is a database used to uniformly store the status data of each block in the blockchain; the first node belongs to the blockchain;

[0157] Result receiving module 12 is used to receive the data query results returned by the status database based on the data query request;

[0158] The write request sending module 13 is used to send a data write request for the target transaction status data to the status database if the data query result is a query result that does not contain the target transaction status data in the status database. The data write request is used to request the status database to write the target transaction status data into the status database. The target transaction status data in the status database has a shared access attribute. The target transaction status data with the shared access attribute is used for the first node and the second node to share and access the data. The second node belongs to the blockchain.

[0159] The specific implementation methods of the query request sending module 11, the result receiving module 12, and the write request sending module 13 can be found in the above description. Figure 3 The descriptions of steps S101-S103 in the corresponding embodiments will not be repeated here.

[0160] In one embodiment, the blockchain-based data processing device 1 may further include: a verification module 14, a local writing module 15, and an attribute determination module 16.

[0161] The verification module 14 is used to verify the consistency of the target transaction status data based on the existence proof if the data query result is a query result containing an existence proof, and to obtain the verification result.

[0162] The local write module 15 is used to write the target transaction status data to the local database of the first node if the verification result is a verification failure result.

[0163] The attribute determination module 16 is used to determine the write attribute of the target transaction status data as a written attribute if the verification result is a verification pass result.

[0164] The specific implementation methods of the verification module 14, the local writing module 15, and the attribute determination module 16 can be found in the above description. Figure 4 The descriptions of steps S401-S404 in the corresponding embodiments will not be repeated here.

[0165] In one embodiment, the proof of existence includes a target Merkle root for the target transaction state data of the target block;

[0166] The verification module 14 may include: a hash acquisition unit 141, a generation unit 142, a matching unit 143, and a result determination unit 144.

[0167] The hash acquisition unit 141 is used to acquire the existing state hash value corresponding to the existing block; the existing block refers to the block in the blockchain whose block height is less than the target block, and the write attribute of the transaction state data of the existing block is the written attribute.

[0168] The generation unit 142 is used to obtain the target state hash value of the target transaction state data, and generate a Merkle root to be matched for the target transaction state data based on the existing state hash value and the target state hash value.

[0169] Matching unit 143 is used to match the Merkle root to be matched with the target Merkle root;

[0170] The result determination unit 144 is used to determine the verification result as a verification pass result if the Merkle root to be matched is the same as the target Merkle root.

[0171] The result determination unit 144 is also used to determine the verification result as a verification failure result if the Merkle root to be matched is different from the target Merkle root.

[0172] The specific implementation methods of the hash acquisition unit 141, generation unit 142, matching unit 143, and result determination unit 144 can be found in the above description. Figure 4 The description of step S401 in the corresponding embodiment will not be repeated here.

[0173] In one embodiment, the write request sending module 13 may include: a block information acquisition unit 131, a version number determination unit 132, a request generation unit 133, and a write request sending unit 134.

[0174] The block information acquisition unit 131 is used to acquire the transaction identifier of the transaction data contained in the target block, as well as the block height of the target block;

[0175] Version number determination unit 132 is used to use the block height of the target block and the transaction identifier as the data version number of the target transaction status data;

[0176] The request generation unit 133 is used to establish a mapping relationship between the data version number and the target transaction status data, and generate a data write request containing the target transaction status data and the mapping relationship.

[0177] The write request sending unit 134 is used to send a data write request containing target transaction status data and mapping relationship to the status database, determine that the data write request is for the target transaction status data.

[0178] The specific implementation methods of the block information acquisition unit 131, the version number determination unit 132, the request generation unit 133, and the write request sending unit 134 can be found in the above description. Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0179] In one embodiment, the blockchain-based data processing device 1 may further include: a receiving module 17, a read request sending module 18, and a status detection module 19.

[0180] Receiving module 17 is used to receive the data writing result returned by the status database based on the data writing request;

[0181] The read request sending module 18 is used to send a data read request carrying a data version number to the status database when the read time for the target transaction status data is reached if the data write result is a successful write result. The data read request is used to request to read the target transaction status data. The read time is later than the write time. The write time refers to the time when the first node successfully writes the target transaction status data to the status database.

[0182] The status detection module 19 is used to receive the data reading result returned by the status database based on the data reading request, and to perform storage status detection on the target transaction status data based on the data reading result.

[0183] The specific implementation methods of the receiving module 17, the read request sending module 18, and the status detection module 19 can be found in the above description. Figure 6 The descriptions of steps S601-S603 in the corresponding embodiments will not be repeated here.

[0184] In one embodiment, the state detection module 19 may include a first state determination unit 191 and a second state determination unit 192.

[0185] The first state determination unit 191 is used to determine the storage state of the target transaction state data as normal if the data reading result is a reading result carrying the target transaction state data.

[0186] The second state determination unit 192 is used to determine the storage state of the target transaction state data as an abnormal state if the data reading result is a reading result that does not contain the target transaction state data in the state database; the abnormal state is used to indicate that the state database has moved the target transaction state data out of the state database based on the storage limit value of the state database.

[0187] The specific implementation methods of the first state determination unit 191 and the second state determination unit 192 can be found in the above description. Figure 6 The description of step S103 in the corresponding embodiment will not be repeated here.

[0188] In one embodiment, the status detection module 19 may further include a local writing unit 193.

[0189] The local write unit 193 is used to write the target transaction status data to the local database of the first node if the storage status of the target transaction status data is abnormal.

[0190] For details on the implementation of the local write unit 193, please refer to the above. Figure 6 The description of step S603 in the corresponding embodiment will not be repeated here.

[0191] In one embodiment, at the time of reading, the block height of the target block is the maximum block height in the local block height set corresponding to the first node; the local block height set is a set consisting of the block heights corresponding to N local blocks stored in the local database of the first node, and the N local blocks include the target block; N is a positive integer;

[0192] The status detection module 19 may also include a node marking unit 194.

[0193] The node marking unit 194 is used to mark the first node as a synchronization lag node when the storage state of the target transaction state data is in an abnormal state; when executing the consensus business of the block to be consensus, the voting information of the synchronization lag node for the consensus business is invalid voting information; the block generation time of the block to be consensus is later than the block generation time of the target block.

[0194] For a detailed implementation of the node marking unit 194, please refer to the above. Figure 6 The description of step S603 in the corresponding embodiment will not be repeated here.

[0195] In one embodiment, the blockchain-based data processing device 1 may further include: a traversal module 21 and a step execution module 22.

[0196] Traversal module 21 is used to traverse the set of existing state data stored in the local database of the first node when the time for reading the target transaction state data is reached; the set of existing state data contains one or more existing state data stored in the local database.

[0197] The step execution module 22 is used to execute the step of sending a data read request carrying a data version number to the status database if the target transaction status data is not found in one or more existing status data stored in the local database.

[0198] The specific implementation methods of the traversal module 21 and the step execution module 22 can be found in the above description. Figure 6 The description of step S603 in the corresponding embodiment will not be repeated here.

[0199] In one embodiment, the moment when the first node sends a data query request to the state database is the first moment; the time period in which the target transaction state data is contained in the state database is the time period composed of the second moment and the third moment. The second moment is the moment when the second node writes the target transaction state data into the state database, and the third moment is the moment when the state database moves the target transaction state data out of the state database based on the storage limit of the state database; the first moment and the third moment are both later than the second moment, and the third moment is earlier than the first moment; the second node belongs to the blockchain.

[0200] In one embodiment, the blockchain-based data processing device 1 may further include: a prompt receiving module 23 and a local status writing module 24.

[0201] The prompt receiving module 23 is used to receive the duplicate write prompt information returned by the status database based on the data write request; the duplicate write prompt information is used to prompt that the target transaction status data is duplicate write data for the status database;

[0202] The local status writing module 24 is used to write the target transaction status data to the local database of the first node according to the repeated write prompt information.

[0203] The specific implementation methods of the prompt receiving module 23 and the local status writing module 24 can be found in the above description. Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0204] In one embodiment, the blockchain-based data processing device 1 may further include a lagging marker module 25.

[0205] The lagging marker module 25 is used to mark the first node as a synchronous lagging node based on the repeated write prompt information; when executing the consensus business of the block to be consensused, the voting information of the synchronous lagging node for the consensus business is invalid voting information; the block generation time of the block to be consensused is later than the block generation time of the target block.

[0206] The specific implementation of the lagging marker module 25 can be found in the above description. Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0207] In this embodiment, a unified state database is used to store the transaction state data of different nodes (such as the first node and the second node) in the blockchain. Each node can write the transaction state data of its local block into the state database. To reduce duplicate writes, each node can send a data query request to the state database before writing the transaction state data of a certain block. If the state database does not contain the transaction state data, the node can write the transaction state data into the state database. The transaction state data stored in the state database has a shared access attribute, and all nodes in the blockchain can share and access it. It should be understood that by using a unified state database to store the transaction state data of different nodes, the transaction state data of each node can be stored in a unified location, thereby improving the situation where the data stored locally by each node is consistent, reducing data redundancy, and thus reducing the overall storage space consumption of the blockchain.

[0208] Further, please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 10 As shown above, Figure 9The blockchain-based data processing device 1 in the corresponding embodiment can be applied to the aforementioned computer device 8000. The computer device 8000 may include a processor 8001, a network interface 8004, and a memory 8005. Furthermore, the computer device 8000 also includes a user interface 8003 and at least one communication bus 8002. The communication bus 8002 is used to enable communication between these components. The user interface 8003 may include a display screen and a keyboard; optionally, the user interface 8003 may also include a standard wired interface or a wireless interface. The network interface 8004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 8005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 8005 may also be at least one storage device located remotely from the aforementioned processor 8001. Figure 10 As shown, the memory 8005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0209] exist Figure 10 In the computer device 8000 shown, the network interface 8004 provides network communication functionality; the user interface 8003 is mainly used to provide an input interface for the user; and the processor 8001 can be used to call the device control application program stored in the memory 8005 to achieve:

[0210] Send a data query request for the target transaction status data to the state database; the target transaction status data refers to the status data of the transaction data contained in the target block; the state database is a database used to uniformly store the status data of each block in the blockchain; the first node belongs to the blockchain;

[0211] Receive the data query results returned by the status database based on the data query request;

[0212] If the data query result is a query result that does not contain the target transaction status data in the status database, a data write request for the target transaction status data is sent to the status database. The data write request is used to request that the target transaction status data be written to the status database. The target transaction status data in the status database has a shared access attribute. The target transaction status data with the shared access attribute is used for the first node and the second node to share and access the data. The second node belongs to the blockchain.

[0213] It should be understood that the computer device 8000 described in the embodiments of this application can execute the foregoing text. Figures 3 to 6The description of the blockchain-based data processing method in the corresponding embodiments can also be performed as described above. Figure 9 The description of the blockchain-based data processing device 1 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0214] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing computer device 8000. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figures 3 to 6 The description of the blockchain-based data processing method in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0215] The aforementioned computer-readable storage medium can be the internal storage unit of the blockchain-based data processing apparatus provided in any of the foregoing embodiments or the computer device, such as the hard drive or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0216] One aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in one aspect of the embodiments of this application.

[0217] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0218] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0219] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0220] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on blockchain, characterized in that, include: The first node sends a data query request for the target transaction status data to the status database; The target transaction status data refers to the status data of the transaction data contained in the target block; the status database refers to a database used to uniformly store the status data of each block in the blockchain. The first node belongs to the blockchain; Receive the data query results returned by the status database based on the data query request; If the data query result is a query result in which the target transaction status data is not contained in the status database, then a data write request for the target transaction status data is sent to the status database; the data write request is used to request that the target transaction status data be written to the status database. The target transaction status data in the status database has a shared access attribute. The target transaction status data with the shared access attribute is used for shared access between the first node and the second node, where the second node belongs to the blockchain. If the data query result contains a proof of existence, the consistency of the target transaction state data is verified based on the proof of existence to obtain a verification result; wherein, the proof of existence contains a target Merkle root for the target transaction state data of the target block; the verification of the consistency of the target transaction state data based on the proof of existence to obtain a verification result includes: obtaining the existing state hash value corresponding to the existing block; the existing block refers to a block in the blockchain whose block height is less than the target block, and the write attribute of the transaction state data of the existing block is a written attribute; obtaining the target state hash value of the target transaction state data, and generating a Merkle root to be matched for the target transaction state data based on the existing state hash value and the target state hash value; matching the Merkle root to be matched with the target Merkle root; if the Merkle root to be matched is the same as the target Merkle root, the verification result is determined as a verification pass result; if the Merkle root to be matched is different from the target Merkle root, the verification result is determined as a verification failure result. If the verification result is a verification failure, the target transaction status data is written to the local database of the first node; if the verification result is a verification success, the write attribute of the target transaction status data is determined to be a written attribute.

2. The method according to claim 1, characterized in that, Sending a data write request for the target transaction status data to the status database includes: Obtain the transaction identifier of the transaction data contained in the target block, and the block height of the target block; The block height of the target block and the transaction identifier are used as the data version number of the target transaction status data; Establish a mapping relationship between the data version number and the target transaction status data, and generate a data write request containing the target transaction status data and the mapping relationship; The data write request containing the target transaction status data and the mapping relationship is determined as a data write request for the target transaction status data, and the data write request for the target transaction status data is sent to the status database.

3. The method according to claim 2, characterized in that, The method further includes: Receive the data write result returned by the status database based on the data write request; If the data writing result is a successful write result, then when the time for reading the target transaction status data is reached, a data read request carrying the data version number is sent to the status database; the data read request is used to request to read the target transaction status data; the read time is later than the write time, and the write time refers to the time when the first node successfully writes the target transaction status data to the status database; Receive the data read result returned by the status database based on the data read request, and perform storage status detection on the target transaction status data based on the data read result.

4. The method according to claim 3, characterized in that, The storage status detection of the target transaction status data based on the data reading result includes: If the data reading result is a reading result carrying the target transaction status data, then the storage status of the target transaction status data is determined to be a normal state; If the data reading result is that the target transaction status data is not included in the status database, then the storage status of the target transaction status data is determined to be an abnormal state; the abnormal state is used to indicate that the status database has moved the target transaction status data out of the status database based on the storage limit value of the status database.

5. The method according to claim 4, characterized in that, The method further includes: If the storage status of the target transaction status data is abnormal, then the target transaction status data is written to the local database of the first node.

6. The method according to claim 4, characterized in that, At the time of reading, the block height of the target block is the maximum block height in the local block height set corresponding to the first node; the local block height set is a set consisting of the block heights of N local blocks stored in the local database of the first node, including the target block; N is a positive integer; The method further includes: When the storage status of the target transaction status data is in an abnormal state, the first node is marked as a synchronization lag node; when executing the consensus service of the subsequent block, the voting information of the synchronization lag node for the consensus service is invalid voting information; the block generation time of the block to be consensus is later than the block generation time of the target block.

7. The method according to claim 3, characterized in that, The method further includes: When the time for reading the target transaction status data is reached, the set of existing status data stored in the local database of the first node is traversed; the set of existing status data contains one or more existing status data stored in the local database. If the target transaction status data is not present in one or more existing status data stored in the local database, then the step of sending a data read request carrying the data version number to the status database is executed.

8. The method according to claim 1, characterized in that, The moment when the first node sends the data query request to the state database is the first moment; the time period in which the target transaction state data is contained in the state database is the time period composed of the second moment and the third moment, where the second moment is the moment when the second node writes the target transaction state data into the state database, and the third moment is the moment when the state database moves the target transaction state data out of the state database based on the storage limit of the state database; both the first moment and the third moment are later than the second moment, and the third moment is earlier than the first moment; the second node belongs to the blockchain.

9. The method according to claim 8, characterized in that, The method further includes: Receive duplicate write prompt information returned by the status database based on the data write request; the duplicate write prompt information is used to indicate that the target transaction status data is duplicate write data for the status database; Based on the repeated write prompt message, the target transaction status data is written to the local database of the first node.

10. The method according to claim 9, characterized in that, The method further includes: Based on the repeated write prompt information, the first node is marked as a synchronization lag node; when executing the consensus service of the block to be consensused, the voting information of the synchronization lag node for the consensus service is invalid voting information; the block generation time of the block to be consensused is later than the block generation time of the target block.

11. A data processing device based on blockchain, characterized in that, include: The request sending module is used to send data query requests for target transaction status data to the status database; The target transaction status data refers to the status data of the transaction data contained in the target block; the status database refers to a database used to uniformly store the status data of each block in the blockchain; the first node belongs to the blockchain; The result receiving module is used to receive the data query results returned by the status database based on the data query request; The write request sending module is used to send a data write request for the target transaction status data to the status database if the data query result is a query result in the status database that does not contain the target transaction status data; the data write request is used to request the status database to write the target transaction status data into the status database; The target transaction status data in the status database has a shared access attribute. The target transaction status data with the shared access attribute is used for shared access between the first node and the second node, where the second node belongs to the blockchain. The verification module is used to verify the consistency of the target transaction state data based on the existence proof if the data query result contains an existence proof, thereby obtaining a verification result; wherein, the existence proof contains the target Merkle root of the target transaction state data for the target block; the verification of the consistency of the target transaction state data based on the existence proof to obtain the verification result includes: obtaining the existing state hash value corresponding to the existing block; the existing block refers to a block in the blockchain whose block height is less than the target block. The write attribute of the transaction status data of the existing block is set to "written"; the target status hash value of the target transaction status data is obtained; based on the existing status hash value and the target status hash value, a Merkle root to be matched for the target transaction status data is generated; the Merkle root to be matched is matched with the target Merkle root; if the Merkle root to be matched is the same as the target Merkle root, the verification result is determined as a verification pass result; if the Merkle root to be matched is different from the target Merkle root, the verification result is determined as a verification failure result. The local write module is used to write the target transaction status data to the local database of the first node if the verification result is a verification failure result; The attribute determination module is used to determine the write attribute of the target transaction status data as a written attribute if the verification result is a verification pass result.

12. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication functions, the memory is used to store computer programs, and the processor is used to call the computer programs to cause the computer device to execute the method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method according to any one of claims 1-10.

14. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, the computer program being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-10.

Images