A data processing method based on a blockchain network and related equipment

Abstract

Embodiments of the present application provide a data processing method based on a blockchain network and related equipment, the blockchain network includes a plurality of nodes, the nodes include light nodes or full nodes, the method is executed by a target full node in the blockchain network; the method comprises: receiving a data synchronization request sent by a target light node in the blockchain network; in response to the data synchronization request, finding transaction hashes of visible transactions of the target light node in the blockchain, the visible transactions refer to transactions that allow the target light node to access; determining transaction hashes of uncached transactions of the target light node in the transaction hashes of the visible transactions, the uncached transactions refer to the visible transactions that are not cached to the cache space of the target light node; according to the transaction hashes of the uncached transactions, obtaining transaction data of the uncached transactions from the blockchain, and synchronizing the transaction data of the uncached transactions to the target light node for storage. By using the embodiments of the present application, the data synchronization pressure of the full nodes in the blockchain network can be reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to the field of blockchain technology, specifically to a data processing method and related equipment based on a blockchain network. Background Technology

[0002] In a blockchain network, light nodes and full nodes need to synchronize data. Data synchronization refers to light nodes requesting transaction data from full nodes, and full nodes synchronizing the requested transaction data back to light nodes. Currently, light nodes in blockchain networks do not support storing transaction data. Therefore, whenever a light node needs transaction data, it sends a request to the full node. In this data synchronization scheme, if light nodes frequently need transaction data, or if multiple light nodes simultaneously request transaction data synchronization from the full node, the full node will repeatedly receive requests, query transaction data, and synchronize transaction data, thus placing significant data synchronization pressure on the full node. Summary of the Invention

[0003] This application provides a data processing method and related equipment based on a blockchain network, which can reduce the data synchronization pressure of all nodes in the blockchain network.

[0004] On one hand, embodiments of this application provide a data processing method based on a blockchain network. The blockchain network includes multiple nodes, including light nodes or full nodes. The method is executed by a target full node in the blockchain network, and the method includes:

[0005] Receive data synchronization requests sent by target light nodes in the blockchain network;

[0006] In response to a data synchronization request, find the transaction hash of the visible transactions of the target light node in the blockchain. Visible transactions are those that the target light node is allowed to access.

[0007] Determine the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transactions. The uncached transaction refers to the visible transaction that is not cached in the cache space of the target light node.

[0008] Based on the transaction hash of the uncached transaction, retrieve the transaction data of the uncached transaction from the blockchain and synchronize the transaction data of the uncached transaction to the target light node for storage.

[0009] In this embodiment, when a full node receives a data synchronization request from a light node, it can synchronize transaction data of transactions visible to the light node but not cached. The light node can store the synchronized transaction data. Visible but uncached transactions refer to transactions that are accessible to the light node but not cached in its cache space. On one hand, the light node in this embodiment supports storing transaction data. After storing the visible but uncached transaction data synchronized by the full node, the light node can directly retrieve the transaction data locally when needed, without requesting the full node again, thus reducing the data synchronization pressure on the full node. On the other hand, the full node synchronizes only the visible but uncached transaction data of the light node, filtering out the cached transaction data in the light node's cache space. This reduces the amount of data synchronized and also alleviates the data synchronization pressure on the full node.

[0010] On the other hand, embodiments of this application provide a data processing method based on a blockchain network. The blockchain network includes multiple nodes, including light nodes or full nodes. The method is executed by a target light node in the blockchain network, and the method includes:

[0011] A data synchronization request is sent to the target full node in the blockchain network. In response to the data synchronization request, the target full node searches for the transaction hash of the visible transactions of the target light node in the blockchain, determines the transaction hash of the uncached transactions of the target light node from the transaction hash of the visible transactions, and returns the transaction data of the uncached transactions based on the transaction hash of the uncached transactions. Visible transactions refer to transactions that are allowed to be accessed by the target light node, and uncached transactions refer to visible transactions that are not cached in the cache space of the target light node.

[0012] Receive transaction data of uncached transactions synchronized by the target full node, and store the transaction data of uncached transactions.

[0013] In this embodiment, a light node can send a data synchronization request to a full node, requesting the synchronization of transaction data that is visible to the light node but not cached from the full node. The light node can then store the transaction data synchronized by the full node. Here, "visible but not cached transactions" refers to transactions that are accessible to the light node but not cached in its cache space. On one hand, the light node in this embodiment supports storing transaction data. After storing the visible but not cached transaction data synchronized by the full node, the light node can directly retrieve the transaction data locally when needed, without requesting the full node again, thus reducing the data synchronization pressure on the full node. On the other hand, the full node synchronizes only the visible but not cached transaction data of the light node, filtering out the cached transaction data in the light node's cache space. This reduces the amount of data synchronized and also alleviates the data synchronization pressure on the full node.

[0014] Accordingly, this application provides a data processing device based on a blockchain network. The blockchain network includes multiple nodes, including light nodes or full nodes. The device is located in a target full node of the blockchain network and includes:

[0015] The communication unit is used to receive data synchronization requests sent by the target light node in the blockchain network.

[0016] The processing unit is used to respond to data synchronization requests by finding the transaction hash of the visible transactions of the target light node in the blockchain. Visible transactions refer to transactions that the target light node is allowed to access.

[0017] The processing unit is also used to determine the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transactions. The uncached transaction refers to the visible transaction that is not cached in the cache space of the target light node.

[0018] The processing unit is also used to retrieve transaction data of uncached transactions from the blockchain based on the transaction hash of the uncached transactions;

[0019] The communication unit is also used to synchronize transaction data of uncached transactions to the target light node for storage.

[0020] In one implementation, when the processing unit determines the transaction hash of the uncached transaction of the target light node from the transaction hashes of visible transactions, it specifically performs the following steps:

[0021] The transaction hash of the visible transactions is sent to the target light node; the target light node filters the transaction hash of the visible transactions based on the transaction hash of the cached transactions in the target light node's cache space to obtain the transaction hash of the uncached transactions of the target light node, and sends the transaction hash of the uncached transactions to the target full node;

[0022] Receive the transaction hash of the uncached transaction sent by the target light node.

[0023] In one implementation, the data synchronization request includes the transaction hashes of cached transactions in the target light node's cache space; the processing unit, when determining the transaction hashes of uncached transactions of the target light node from the transaction hashes of visible transactions, specifically performs the following steps:

[0024] Based on the transaction hashes of cached transactions, the transaction hashes of visible transactions are filtered to obtain the transaction hashes of uncached transactions of the target light node.

[0025] In one implementation, the data synchronization request includes the target block height that the target light node is requesting to synchronize;

[0026] The processing unit, when searching for the transaction hash of a visible transaction of a target light node in the blockchain, specifically performs the following steps: determining the target block corresponding to the target block height in the blockchain; and searching for the transaction hash of a visible transaction of the target light node in the target block.

[0027] The processing unit, when retrieving transaction data of uncached transactions from the blockchain based on the transaction hash of the uncached transactions, specifically performs the following steps: retrieving transaction data of uncached transactions from the target block based on the transaction hash of the uncached transactions.

[0028] In one implementation, the data synchronization request includes the node identifier of the target light node, which is associated with the transaction identifier of the visible transaction; the processing unit, when searching for the transaction hash of the visible transaction of the target light node in the blockchain, specifically performs the following steps:

[0029] Based on the node identifier of the target light node, retrieve the transaction identifier of the visible transactions associated with the node identifier of the target light node from the blockchain;

[0030] Based on the transaction identifier of the visible transaction, obtain the transaction hash of the visible transaction of the target light node from the blockchain.

[0031] In one implementation, the communication unit is further configured to perform the following steps: receiving the node identifier of a visible light node sent by the target light node, wherein the visible light node is a light node in the blockchain network set up by the target light node that is allowed to access the target transaction;

[0032] The processing unit is also used to perform the following steps: establishing the association between the node identifier of the visible light node and the transaction identifier of the target transaction; and uploading the association between the node identifier of the visible light node and the transaction identifier of the target transaction to the blockchain.

[0033] Accordingly, this application provides a data processing device based on a blockchain network. The blockchain network includes multiple nodes, including light nodes or full nodes. The device is installed in a target light node of the blockchain network and includes:

[0034] The communication unit is used to send a data synchronization request to the target full node in the blockchain network. In response to the data synchronization request, the target full node searches for the transaction hash of the visible transactions of the target light node in the blockchain, determines the transaction hash of the uncached transactions of the target light node from the transaction hash of the visible transactions, and returns the transaction data of the uncached transactions based on the transaction hash of the uncached transactions. Visible transactions refer to transactions that are allowed to be accessed by the target light node, and uncached transactions refer to visible transactions that are not cached in the cache space of the target light node.

[0035] The communication unit is also used to receive transaction data of unbuffered transactions synchronized by the target full node;

[0036] The processing unit is used to store transaction data for transactions that are not cached.

[0037] In one implementation, the processing unit is further configured to perform the following steps: obtain the target block height and the highest block height of the blockchain that the target light node requests to synchronize; if the target block height is less than or equal to the highest block height, generate a data synchronization request based on the target block height, and trigger the communication unit to execute the step of sending the data synchronization request to the target node in the blockchain network;

[0038] Among them, the transaction hash of the visible transaction and the transaction data of the uncached transaction are obtained by the target full node in the target block corresponding to the target block height.

[0039] In one implementation, the processing unit is further configured to perform the following steps: update the target block height using the target value to obtain the updated target block height;

[0040] If the updated target block height is less than or equal to the highest block height, an updated data synchronization request is generated based on the updated target block height, and data synchronization requests are continued to be sent to the target full node based on the updated data synchronization request until the updated target block height is greater than the highest block height.

[0041] In one implementation, the communication unit is further configured to perform the following steps: receiving a transaction request for a target transaction sent by a client, and forwarding the transaction request for the target transaction to the target full node; the target full node responds to the transaction request, executes the target transaction, generates and returns the transaction execution result of the target transaction, the transaction execution result including the transaction hash of the target transaction; and receives the transaction execution result of the target transaction.

[0042] The processing unit is also configured to perform the following steps: generate transaction data for the target transaction based on the transaction execution result and the transaction request of the target transaction, and cache the transaction data of the target transaction in the cache space of the target light node;

[0043] The communication unit is also used to perform the following steps: forwarding the transaction execution result of the target transaction to the client.

[0044] In one implementation, the processing unit is further configured to perform the following steps: when the cache cleanup conditions are met, delete the transaction data of the cached transactions in the cache space of the target light node;

[0045] The cache cleanup conditions include: the target light node's cache space reaching the cache limit, and the end time of the cache cycle being reached.

[0046] Accordingly, this application provides a computer device based on a blockchain network. The blockchain network includes multiple nodes, including light nodes or full nodes. The device is a target full node or a target light node in the blockchain network. The device includes a processor and a computer-readable storage medium, wherein the processor is adapted to implement a computer program, the computer-readable storage medium stores the computer program, and the computer program is adapted to be loaded by the processor and executed by the processor to perform the above-described data processing method based on the blockchain network.

[0047] Accordingly, embodiments of this application provide a computer-readable storage medium storing a computer program. When the computer program is read and executed by the processor of a computer device, the computer device performs the aforementioned data processing method based on a blockchain network.

[0048] Accordingly, embodiments of this application provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The 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 aforementioned data processing method based on a blockchain network.

[0049] In this embodiment, during data synchronization between the full node and the light node, the full node synchronizes transaction data of visible but uncached transactions to the light node. The light node can then store this synchronized transaction data. Visible but uncached transactions refer to transactions that are accessible to the light node and not cached in its cache space. On one hand, the light node in this embodiment supports storing transaction data. After storing the synchronized transaction data, the light node can directly retrieve the data locally when needed, without requesting the full node again, thus reducing the data synchronization pressure on the full node. On the other hand, the full node synchronizes only the visible but uncached transaction data of the light node, filtering out cached transaction data in the light node's cache space. This reduces the amount of data synchronized and also alleviates the data synchronization pressure on the full node. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0052] Figure 2a This is a flowchart illustrating a data synchronization scheme in a tax scenario provided in an embodiment of this application;

[0053] Figure 2b This is a flowchart illustrating another data synchronization scheme for a tax scenario provided in this application embodiment;

[0054] Figure 3 This is a schematic diagram of the architecture of a blockchain network provided in an embodiment of this application;

[0055] Figure 4 This is a flowchart illustrating a data processing method based on a blockchain network provided in an embodiment of this application;

[0056] Figure 5 This is a flowchart illustrating another data processing method based on a blockchain network provided in an embodiment of this application;

[0057] Figure 6a This is a flowchart illustrating an exemplary data synchronization process provided in an embodiment of this application;

[0058] Figure 6b This is a flowchart illustrating another exemplary data synchronization process provided in an embodiment of this application;

[0059] Figure 6c This is a flowchart illustrating a block generation process provided in an embodiment of this application;

[0060] Figure 7 This is a flowchart illustrating another data processing method based on a blockchain network provided in an embodiment of this application;

[0061] Figure 8 This is a flowchart illustrating another data processing method based on a blockchain network provided in an embodiment of this application;

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

[0063] Figure 10 This is a schematic diagram of the structure of a computer device based on a blockchain network provided in an embodiment of this application. Detailed Implementation

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

[0065] To better understand the technical solutions proposed in the embodiments of this application, some key terms involved in the embodiments of this application are introduced below:

[0066] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of blocks linked together using cryptographic methods. Each block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. Figure 1 As shown, a blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block of the blockchain is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0067] A blockchain network is a system for data sharing between nodes. A blockchain network can include multiple nodes, which can be divided into two categories: light nodes and full nodes. Light nodes, also known as SPV (Simplified Payment Verification) nodes, are nodes in the blockchain network that do not participate in consensus but store the headers of all blocks in the blockchain. Typically, light nodes do not support storing transaction data but can synchronize the block headers from full nodes; that is, light nodes store the block headers of all blocks in the blockchain. Full nodes, on the other hand, are nodes in the blockchain network that possess the complete blockchain ledger (i.e., the blockchain itself). Full nodes require memory to synchronize all blockchain data, can independently verify all transactions on the blockchain and update data in real time, and are primarily responsible for broadcasting and verifying blockchain transactions. In other words, full nodes store... Figure 1 The complete blockchain is shown.

[0068] Based on the above descriptions of light nodes and full nodes, the common data synchronization process between light nodes and full nodes is introduced below: When a light node receives a transaction request from a client, the light node does not execute the requested transaction, but forwards the transaction request to the full node, which then executes the requested transaction. After the full node executes the transaction, it determines a transaction data based on the transaction request and the generated transaction execution result, uploads it to the blockchain for storage, and also returns the generated transaction execution result to the light node, which then forwards the transaction execution result to the client that initiated the transaction request.

[0069] by Figure 2a Taking the tax system 20 shown as an example, the tax system 20 is a blockchain network in a tax application scenario. The tax system 20 may include the State Taxation Administration 201 and tax sub-bureaus 202. There can be one or more State Taxation Administration 201 and tax sub-bureaus 202. Each tax sub-bureau 202 can connect to one or more business clients. Figure 2a The tax system 20 shown includes a State Taxation Administration 201 (hereinafter referred to as the target State Taxation Administration 201) and a tax branch 202 (hereinafter referred to as the target tax branch 202). The target tax branch 202 is connected to the first business client 203 and the second business client 204. This is only for example and does not constitute a limitation on the embodiments of this application. The computer equipment used by the State Taxation Administration 201 is a full node in the blockchain network, and the computer equipment used by the tax branch 202 is a light node in the blockchain network.

[0070] The data synchronization process between any State Taxation Administration 201 and any tax sub-bureau is as follows: The first business client 203 initiates a request to the target tax sub-bureau 202 to issue an electronic voucher (e.g., an electronic invoice). Since the target tax sub-bureau 202 does not have the authority to issue electronic vouchers, it forwards the issuance request to the target State Taxation Administration 201. After the target State Taxation Administration 201 issues the electronic voucher to the first business client 203, it can generate a first transaction execution result based on the issued electronic voucher, and generate transaction data based on the first transaction execution result and the issuance request, which is then uploaded to the blockchain for storage. The target State Taxation Administration 201 can also return the first transaction execution result to the target tax sub-bureau 202, and then the target tax sub-bureau 202 can forward the first transaction execution result to the first business client 203, so that the first business client 230 can obtain the electronic voucher from the first transaction execution result.

[0071] The second business client 204 initiates a query request for electronic vouchers (e.g., electronic invoices) to the target tax branch 202. Since the target tax branch 202 does not support storing transaction data and cannot query it, it forwards the query request to the target tax authority 201. The target tax authority 201 can generate a second transaction execution result based on the retrieved electronic voucher, and can also generate transaction data based on the first transaction execution result and the query request, uploading it to the blockchain for storage. The target tax authority 201 can also return the second transaction execution result to the target tax branch 202, which can then forward it to the second business client 204. The second business client 204 can then obtain the electronic voucher from the second transaction execution result. It is clear that whenever the target tax branch 202 (i.e., the light node) needs transaction data, it requests data from the target tax authority 201 (i.e., the full node), placing significant data synchronization pressure on the full nodes in the blockchain network.

[0072] To alleviate the data synchronization pressure on full nodes in a blockchain network, this application proposes a novel data synchronization scheme. In this scheme, any light node in the blockchain network (hereinafter referred to as the target light node) can store transaction data of visible transactions of that target light node. Visible transactions refer to transactions that the target light node is allowed to access. The visible transactions of the target light node can include transactions that the target light node designates to be visible to itself, and can also include transactions that other light nodes in the blockchain network designate to be visible to the target light node. The transactions that the target light node designates to be visible to itself are generally requested by the target light node from the full nodes. Transactions (such as the aforementioned electronic voucher issuance and query requests) are synchronized from the full node to the target light node. The target light node then caches the transaction data of these transactions in its own cache space. However, transaction data of transactions visible to the target light node by other light nodes is not cached in the target light node's cache space and needs to be synchronized from the full node. In other words, in the new data synchronization scheme provided in this application embodiment, the full node can synchronize transaction data visible to the light node but not cached, and the light node can store the transaction data of its visible transactions (including visible but not cached transaction data and visible and cached transaction data). It should be noted that the caching mentioned in this application embodiment refers to temporarily storing data in a cache space. The cache space will be cleared when certain conditions are met (e.g., the cache space overflows or reaches the cache space cleanup time point), and the data in the cache space will be lost after clearing. The storage mentioned in this application embodiment, on the other hand, refers to permanently storing data in a storage space (e.g., a hard drive). Except for data deletion from the storage space or storage space corruption, the data in the storage space will always exist.

[0073] by Figure 2b Taking the tax system 21 shown as an example, the target tax branch 202 can initiate a data synchronization request to the target tax administration 201; the target tax administration 201 can respond to the data synchronization request by searching for transaction data that is visible to the target tax branch 202 and not cached in the blockchain, and return the transaction data that is visible to the target tax branch 202 and not cached to the target tax branch 202; the target tax branch 202 can store the visible and uncached transaction data.

[0074] For the electronic voucher issuance request initiated by the first business client 203, apart from the target tax branch 202 generating transaction data based on the issuance request and the first transaction execution result containing the issued electronic voucher, and caching the transaction data in the target tax branch 202's cache space, the rest of the process is the same as... Figure 2a The same applies. Regarding the query request for electronic vouchers initiated by the second business client 204, since the target tax branch 202 can support storing transaction data and stores transaction data visible to the target tax branch 202, the target tax branch 202 can directly query the second transaction execution result from the transaction data of visible transactions stored in the target tax branch 202's storage space, and return the queried second transaction execution result to the second business client 204. As can be seen, since light nodes support storing transaction data of visible transactions, when a light node needs transaction data, it only needs to look it up in its own storage space without requesting it from the full node. This greatly reduces the data synchronization pressure on the full node. In addition, when the full node synchronizes data with the light node, it synchronizes the transaction data of transactions that other light nodes designate are visible to the light node (i.e., visible and uncached transaction data). This part of the transaction data is not cached in the light node's cache space. However, it does not synchronize the transaction data of transactions that the light node designates are visible to itself (i.e., visible and cached transaction data). This part of the transaction data is already cached in the light node's cache space, reducing the amount of data to be synchronized and also reducing the data synchronization pressure on the full node.

[0075] The new data synchronization scheme provided in this application embodiment can be derived from... Figure 3 The blockchain network 30 shown can include one or more light nodes 301 and one or more full nodes 302. Any light node 301 can connect to one or more clients 303. Light nodes 301, full nodes 302 and clients 303 can communicate with each other.

[0076] In this context, any light node can refer to a terminal or a server, any full node can refer to a terminal or a server, and any client can refer to a terminal, software, or application. The terminal mentioned here can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, in-vehicle terminal, smart TV, etc., but is not limited to these. The server mentioned here can be a standalone 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 (Content Delivery Network), and big data and artificial intelligence platforms.

[0077] It is understood that the blockchain network 30 described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. Those skilled in the art will recognize that, with the evolution of blockchain network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems. Furthermore, the "multiple" mentioned in the embodiments of this application refers to two or more quantities, as stated herein.

[0078] The following is combined Figures 4 to 8 The illustrated embodiments provide a more detailed description of the novel data synchronization scheme provided by the embodiments of this application.

[0079] This application proposes a data processing method based on a blockchain network. This method primarily describes the data synchronization process on the full node side. Specifically, this data processing method can be executed by any of the aforementioned full nodes (hereinafter referred to as the target full node). For example... Figure 4 As shown, the blockchain-based data processing method may include the following steps S401 to S405:

[0080] S401 receives a data synchronization request sent by a target light node in the blockchain network.

[0081] A target full node can receive data synchronization requests sent by a target light node. A target full node is any full node in the blockchain network, and a target light node is any light node in the blockchain network.

[0082] S402, in response to a data synchronization request, locates the transaction hash of the visible transactions of the target light node in the blockchain.

[0083] After receiving a data synchronization request from a target light node in the blockchain network, the target full node can respond to the data synchronization request by searching for the transaction hash of the target light node's visible transactions in the blockchain; where visible transactions of the target light node refer to transactions that the target light node is allowed to access, and the number of visible transactions of the target light node can be one or more.

[0084] Finding the transaction hash of visible transactions for a target light node in a blockchain can refer to finding the transaction hash of visible transactions within a specified block of the blockchain. The specified block can include: the target block in the blockchain corresponding to the target block height that the target light node requests to synchronize, or it can include: the target block in the blockchain corresponding to the heights of all unsynchronized blocks located between the highest synchronized block height of the target light node and the highest block height of the blockchain (including the highest block height of the blockchain). These two scenarios are described below:

[0085] (1) The specified block may include: the target block in the blockchain corresponding to the target block height requested by the target light node for synchronization. The block height of any block refers to the position of the block in the blockchain, and the target block height refers to the block height of the block that follows the highest block height already synchronized by the target light node in the blockchain. That is, the target block height can be equal to the highest block height already synchronized by the target light node plus 1. In this method, the data synchronization request may include the target block height requested by the target light node for synchronization and the node identifier of the target light node. The node identifier of any light node in the blockchain network can uniquely identify a light node, and the node identifier of each light node is associated with the transaction identifiers of the visible transactions of each light node. That is, the node identifier of the target light node and the transaction identifiers of the visible transactions of the target light node are associated and stored in the blockchain. The node identifier of the target light node and the transaction identifiers of the visible transactions of the target light node are associated, and any transaction identifier in the blockchain can uniquely identify a transaction.

[0086] Finding the transaction hash of visible transactions of a target light node in the blockchain can specifically include: determining the target block corresponding to the target block height in the blockchain, and then searching for the transaction hash of visible transactions of the target light node in the target block. Here, the transaction identifier and transaction hash of any transaction are stored in association in the blockchain; therefore, the transaction hash of the associated visible transactions can be found in the blockchain using the transaction identifier of a visible transaction. Finding the transaction hash of visible transactions of a target light node in the target block can specifically include: obtaining the transaction identifier of visible transactions associated with the node identifier of the target light node from the target block; and obtaining the transaction hash of the associated visible transactions of the target light node from the target block based on the transaction identifier of the visible transactions. For example, if the highest block height synchronized by the target light node is 3, then the target light node requests synchronization of the target block height of 4. That is, the target full node searches for the transaction hash of visible transactions of the target light node in the target block with target block height 4. In this way, the target light node can request the target full node to synchronize the visible and uncached transaction data in each block in the order of the blocks in the blockchain. On the one hand, this can ensure that the amount of data synchronized at one time is not too large, reducing the data synchronization pressure on the target full node. On the other hand, it can also avoid the situation of missing one or more blocks during synchronization.

[0087] (2) The specified block may include: the target block in the blockchain corresponding to all unsynchronized block heights located between the highest synchronized block height of the target light node and the highest block height of the blockchain (including the highest block height of the blockchain). In this method, the number of target blocks can be one or more, and the data synchronization request may include all unsynchronized block heights and the node identifier of the target light node; finding the transaction hash of the visible transactions of the target light node in the blockchain may specifically include: determining one or more target blocks corresponding to all unsynchronized block heights in the blockchain, and then finding the transaction hash of the visible transactions of the target light node in each target block. Specifically, finding the transaction hash of the visible transactions of the target light node in each target block may include: obtaining the transaction identifier of the visible transactions associated with the node identifier of the target light node from each target block based on the node identifier of the target light node; and obtaining the transaction hash of the visible transactions of the associated target light node from each target block based on the transaction identifier of the visible transactions. For example, if the highest block height synchronized by the target light node is 3, and the highest block height of the blockchain is 5, then the target light node can request the target full node to synchronize visible and uncached transaction data in the unsynchronized target blocks at block heights of 3 and 4. In this way, the target light node can request the target full node to synchronize visible and uncached transaction data from multiple blocks at once, reducing the data synchronization burden on the target full node while improving data synchronization efficiency.

[0088] S403, determine the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transactions.

[0089] After finding the transaction hashes of the visible transactions of the target light node, the transaction hashes of the uncached transactions of the target light node can be determined from these visible transaction hashes. Uncached transactions refer to visible transactions that are not cached in the cache space of the target light node. Determining the transaction hashes of the uncached transactions of the target light node is a process of filtering the found transaction hashes of visible transactions based on the transaction hashes of cached transactions in the cache space of the target light node. The filtering operation can be performed by the target light node or by the target full node. The following describes these two cases respectively:

[0090] (1) The target light node performs the filtering operation. In this method, the transaction hash of the target light node's uncached transactions is determined from the transaction hash of the visible transactions. Specifically, this may include: the target full node sending the transaction hash of the visible transactions to the target light node; the target light node filtering the transaction hash of the visible transactions based on the transaction hash of the cached transactions in its cache space to obtain the transaction hash of the target light node's uncached transactions, and sending the transaction hash of the uncached transactions to the target full node; and the target full node receiving the transaction hash of the uncached transactions sent by the target light node. The process of the target light node filtering the transaction hash of the visible transactions based on the transaction hash of the cached transactions in its cache space to obtain the transaction hash of the target light node's uncached transactions can be understood as deleting the transaction hash of the cached transactions that exist in the transaction hash of the visible transactions from the transaction hash of the visible transactions. The remaining transaction hash of the visible transactions after deletion is the transaction hash of the uncached transactions. For example, the transaction hashes of the visible transactions of the target light node form a set H, and the transaction hashes of the cached transactions in set H that exist in the target light node's cache space form a set H1. The transaction hashes in the difference set H2 between set H and set H1 are the transaction hashes of the uncached transactions. In this way, the process of filtering out the transaction hashes of cached transactions from the transaction hashes of the visible transactions of the target light node is performed by the target light node. The target light node can share the data synchronization pressure of the target full node, thereby reducing the data synchronization pressure of the target full node. Furthermore, in the process of determining uncached transactions, the target light node and the target full node transmit the transaction hashes of the visible transactions instead of the transaction data of the visible transactions, thereby reducing the data synchronization pressure of the target full node by reducing the amount of data transmitted.

[0091] (2) Filtering is performed by the target full node. In this method, the data synchronization request may also include the transaction hashes of cached transactions in the target light node's cache space. The transaction hashes of uncached transactions in the target light node are then determined from the transaction hashes of visible transactions. Specifically, this may include the target full node filtering the transaction hashes of visible transactions based on the transaction hashes of cached transactions in the target light node's cache space included in the data synchronization request. It should be noted that the process of the target full node filtering the transaction hashes of visible transactions based on the transaction hashes of cached transactions in the target light node's cache space is the same as the process of the target light node filtering the transaction hashes of visible transactions based on the transaction hashes of cached transactions in its own cache space, and will not be elaborated further here. Compared to the scheme where the target light node performs the filtering operation, the scheme where the target full node performs the filtering operation can reduce the number of data exchanges between the target full node and the target light node.

[0092] S404: Retrieve transaction data of uncached transactions from the blockchain based on the transaction hash of the uncached transactions.

[0093] Since the transaction hash and transaction data of any transaction are stored together in the blockchain, after determining the transaction hash of an uncached transaction, the target full node can retrieve the transaction data of the uncached transaction from a specified block of the blockchain based on the transaction hash of the uncached transaction.

[0094] S405 synchronizes the transaction data of uncached transactions to the target light node for storage.

[0095] After obtaining transaction data for uncached transactions, the target full node can synchronize the transaction data to the target light node for storage. It should be noted that the target full node can also synchronize the block header of a specified block to the target light node for storage.

[0096] As described above, when the target light node receives a transaction request for a target transaction from a client, it does not execute the requested target transaction. Instead, it forwards the transaction request to the target full node. The target light node can also cache the transaction request in its cache space. The target full node can respond to the transaction request, execute the requested target transaction, upload the transaction request and the generated transaction execution result to the blockchain for storage, and return the generated transaction execution result to the target light node. The transaction execution result may contain the transaction hash of the target transaction, which can be obtained by hashing the transaction request. Hash algorithms may include, but are not limited to, MD4, MD5, SHA1, SHA256, SHA512, etc. The target light node generates the transaction data of the target transaction based on the transaction request and the transaction execution result, and caches the transaction data in its cache space. That is, the transaction data of the target transaction is the transaction data of a cached transaction in the cache space of the target light node. Then, it can forward the transaction execution result of the target transaction to the client that initiated the transaction request. In addition, the target light node can also set visible light nodes for the target transaction and send the node identifiers of these visible light nodes to the target full node. Visible light nodes refer to light nodes in the blockchain network that are allowed to access the target transaction, as set by the target light node. Visible light nodes can include the target light node itself and other light nodes in the blockchain network that are allowed to access the target transaction. The target full node can receive the node identifiers of the visible light nodes sent by the target light node, establish an association between the node identifiers of the visible light nodes and the transaction identifiers of the target transaction, and then upload this association to the blockchain. In other words, the target light node can set visible light nodes for its forwarding transactions. By associating and storing the transaction identifiers of the visible transactions with the node identifiers of the visible light nodes, the target full node can quickly find the transaction identifiers of the visible transactions associated with those node identifiers, and thus quickly find the transaction hash of the visible transactions.

[0097] In this embodiment, during the process of the target full node synchronizing the transaction data of visible transactions of the target light node to the target light node, the target full node first determines the transaction hash of the uncached transactions of the target light node, and then reads the transaction data of the uncached transactions from the blockchain stored in the storage space of the target full node according to the transaction hash of the uncached transactions. Then, it synchronizes the transaction data of the uncached transactions to the target light node for storage, instead of directly reading the transaction data of visible transactions from the blockchain stored in the storage space of the target full node and then filtering it. This not only reduces the consumption of the target full node in reading and storing, but also reduces the amount of data during synchronization, enabling the blockchain network to support more light nodes. The advantages of this embodiment are more obvious when the number of uncached transactions is much smaller than the number of cached transactions.

[0098] This application proposes a data processing method based on a blockchain network. This method primarily describes the data synchronization process on the light node side. Specifically, this data processing method can be executed by any of the aforementioned light nodes (hereinafter referred to as the target light node). For example... Figure 5 As shown, the blockchain-based data processing method may include the following steps S501 to S503:

[0099] S501 sends a data synchronization request to the target full node in the blockchain network.

[0100] S502 receives transaction data of uncached transactions synchronized by the target full node.

[0101] In steps S501 and S502, whenever the blockchain in the blockchain network is updated, the full node can send the updated highest block height of the blockchain to the light node, or the light node can periodically request the highest block height of the blockchain from the full node. For example, the light node can request the highest block height of the blockchain from the full node every 10 minutes, or every half hour. After the target light node obtains the highest block height of the blockchain, it can check its own synchronized highest block height. If the synchronized highest block height is less than the highest block height of the blockchain, it means that the target light node has unsynchronized blocks. The target light node can send a data synchronization request to the target full node to request the synchronization of the transaction data that the target light node can see and has not cached in the unsynchronized blocks. If the synchronized highest block height is equal to the highest block height of the blockchain, it means that the target light node has synchronized the transaction data of all visible and uncached transactions in all blocks of the blockchain. When the target full node receives a data synchronization request, it can respond by searching the blockchain for the transaction hashes of the target light node's visible transactions, determining the transaction hashes of the target light node's uncached transactions from these hashes, and returning the transaction data of the uncached transactions based on these hashes. The target light node can receive the transaction data of the uncached transactions synchronized by the target full node. Here, visible transactions refer to transactions that the target light node is allowed to access, and uncached transactions refer to visible transactions that are not cached in the target light node's cache space.

[0102] As described above, a target light node can request a target full node to synchronize visible and uncached transaction data from a specified block. The specified block can include: the target block in the blockchain corresponding to the height of the target block the target light node requests to synchronize, or it can include: the target block in the blockchain corresponding to the heights of all unsynchronized blocks located between the highest synchronized block height of the target light node and the highest block height of the blockchain (including the highest block height of the blockchain). The data synchronization process in these two cases is described below:

[0103] (1) The specified block may include: the target block in the blockchain corresponding to the target block height requested by the target light node for synchronization. In this method, the target light node can obtain the target block height requested for synchronization and the highest block height of the blockchain. As mentioned above, the target block height can be equal to the highest block height already synchronized by the target light node plus 1. Then, when the target block height is less than or equal to the highest block height of the blockchain, the target light node can generate a data synchronization request based on the target block height and send the data synchronization request to the target full node. The target full node can respond to the data synchronization request by synchronizing the transaction data of the uncached transactions of the target light node in the target block corresponding to the target block height to the target light node. The target light node can receive the transaction data of the uncached transactions in the target block corresponding to the target block height.

[0104] After the target light node receives the transaction data of uncached transactions in the target block corresponding to the target block height, it can update the target block height using a target value. The updated target block height can be equal to the target block height plus the target value (e.g., 1). If the updated target block height is less than or equal to the highest block height, the target light node can generate an updated data synchronization request based on the updated target block height and continue to request data synchronization from the target full node based on the updated data synchronization request until the updated target block height is greater than the highest block height. In other words, the target light node can request the target full node to synchronize the transaction data of uncached transactions starting from the target block corresponding to the target block height, up to the block corresponding to the highest block height of the blockchain. The data synchronization process is performed block by block; after synchronizing the transaction data of uncached transactions in one block, it continues to synchronize the transaction data of uncached transactions in the next block.

[0105] like Figure 6a The data synchronization process shown has a target light node with a highest synchronized block height h0 of 5 ( Figure 6a In the blockchain (blocks filled with dashed lines represent synchronized blocks), the highest block height h2 is 8. Therefore, the target block height h1 requested by the target light node is 6. The target light node can request the target full node to synchronize uncached transaction data from the block h1=6. After receiving the uncached transaction data from the target full node's synchronized block h1=6, the target light node can update the target block height h1, i.e., h1=h1+1. The target light node can then request the target full node to synchronize uncached transaction data from the block h1=7. This process continues until the target light node receives the uncached transaction data from the target full node's synchronized block h1=8.

[0106] (2) The specified block may include: the target block in the blockchain corresponding to all unsynchronized block heights located between the highest synchronized block height of the target light node and the highest block height of the blockchain (including the highest block height of the blockchain). In this method, the target light node can obtain the highest synchronized block height of the target light node and the highest block height of the blockchain. Then, when the highest synchronized block height is less than the highest block height of the blockchain, the target light node can determine the heights of all unsynchronized blocks between the highest synchronized block height and the highest block height of the blockchain. The target light node can generate a data synchronization request based on all unsynchronized block heights and send the data synchronization request to the target full node. The target full node can respond to the data synchronization request by synchronizing the transaction data of the target light node's uncached transactions in the target blocks corresponding to all unsynchronized block heights to the target light node. The target light node can receive the transaction data of uncached transactions in the target blocks corresponding to all unsynchronized block heights. That is, the target light node can request the target full node to synchronize the transaction data of uncached transactions in all unsynchronized blocks with a single request.

[0107] like Figure 6b The data synchronization process shown has a target light node with a highest synchronized block height h0 of 5 ( Figure 6b In the blockchain (blocks filled with dashed lines represent synchronized blocks), the highest block height h2 is 8. Therefore, the unsynchronized block heights h3 of the target light node can be determined to be 6, 7, and 8. The target light node can request the target full node to synchronize the transaction data of uncached transactions from the blocks with h3 = 6, 7, and 8.

[0108] S503 stores transaction data for transactions that are not cached.

[0109] After receiving transaction data of uncached transactions synchronized by the target full node, the target light node can store the transaction data of uncached transactions. Storing the transaction data of uncached transactions means storing the transaction data of uncached transactions in the storage space of the target light node (e.g., a hard drive). In addition to storing the transaction data of uncached transactions in the storage space of the target light node, the target light node can also store the block header synchronized by the target full node in the storage space of the target light node, and store the transaction data of cached transactions in the cache space of the target light node in the storage space of the target light node.

[0110] The reason for storing the cached transaction data in the target light node's cache space into the target light node's storage space is that, when the cleanup conditions are met, the target light node can delete the cached transaction data in its cache space. If the cached transaction data is not stored, it will be lost after the cache space is cleaned up. The cache cleanup conditions can include the target light node's cache space reaching its cache limit (i.e., the target light node's cache space overflowing as described above) or reaching the end time of the cache period (i.e., reaching the cleanup time as described above). For example, if the target light node uses one day as its cache period and performs a cache cleanup once a day at 24:00:00, that is, taking 24:00:00 as the end time of the cache period, the cached transaction data in the target light node's cache space is deleted.

[0111] As described above, when the target light node receives a transaction request for a target transaction from a client, it does not execute the requested target transaction. Instead, it forwards the transaction request to the target full node. The target light node can also cache the transaction request in its cache space. The target full node can respond to the transaction request, execute the requested target transaction, upload the transaction request and the generated transaction execution result to the blockchain for storage, and return the generated transaction execution result to the target light node. The transaction execution result may contain the transaction hash of the target transaction, which can be obtained by hashing the transaction request. The target light node can generate the transaction data of the target transaction based on the transaction request and the transaction execution result, and cache the transaction data in its cache space. That is, the transaction data of the target transaction is the transaction data of a cached transaction in the target light node's cache space, so that the transaction hash of the cached transaction can be quickly found in the cache space. Then, the transaction execution result of the target transaction can be forwarded to the client that initiated the transaction request. In addition, the target light node can also set visible light nodes for the target transaction and send the node identifier of the visible light node to the target full node. A visible light node refers to a light node in the blockchain network that is allowed to access the target transaction. Visible light nodes can include the target light node itself and other light nodes in the blockchain network that are allowed to access the target transaction. The target full node can associate the node identifier of the visible light node with the transaction identifier of the target transaction and store it in the blockchain. In other words, the target light node can set visible light nodes for its forwarding transactions. By associating and storing the transaction identifier of the visible transaction with the node identifier of the visible light node, the target full node can quickly find the transaction identifier of the visible transaction associated with the node identifier, and thus quickly find the transaction hash of the visible transaction.

[0112] It should be noted that, in the embodiments of this application, the target full node uploading transaction data (such as the transaction data generated based on the transaction request and execution result of the target transaction, as mentioned above) to the blockchain for storage refers to the process by which the target full node generates blocks based on the transaction data and adds the generated blocks to the blockchain. The process of generating each block in the blockchain can be found in [reference needed]. Figure 6c When the target full node of the blockchain receives input information (i.e., transaction data), it verifies the input information. After verification, it stores the input information in the memory pool and updates the hash tree used to record the input information. Then, it updates the timestamp to the time when the input information was received and tries different random numbers to calculate the feature value multiple times, so that the calculated feature value can satisfy the following formula:

[0113] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0114] In the above formula, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is re-determined after exceeding the fixed time period; x is a random number; and TARGET is the feature value threshold, which can be determined based on nbits. Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating the block header and block body, thus obtaining the current block. Subsequently, the target full node, based on the node identifiers of other full nodes in the blockchain network, sends the newly generated block to other full nodes. The other full nodes verify the newly generated block and add it to their stored blockchain after verification. Other full nodes can synchronize the newly generated block from the target full node. Light nodes can synchronize the block header of the newly generated block and the transaction data of visible but uncached transactions in the newly generated block from the target full node.

[0115] In this embodiment, the target light node can request the target full node to synchronize the transaction data of uncached transactions in one unsynchronized block at a time. This reduces the amount of data during synchronization, thereby alleviating the data synchronization pressure on the target full node. Alternatively, the target light node can request the target full node to synchronize the transaction data of uncached transactions in all unsynchronized blocks at once, which reduces the number of synchronizations and improves data synchronization efficiency.

[0116] This application proposes a data processing method based on a blockchain network. This method mainly describes the data synchronization process between full nodes and light nodes. Specifically, this data processing method can be executed interactively by any of the aforementioned light nodes (hereinafter referred to as the target light node) and any of the full nodes (hereinafter referred to as the target full node). Figure 7 As shown, the blockchain-based data synchronization scheme may include the following steps S701 to S711:

[0117] S701, the target light node sends a data synchronization request to the target full node.

[0118] The target light node can obtain the highest synchronized block height in the target light node and the highest block height of the blockchain. When the highest synchronized block height is less than the highest block height of the blockchain, the target light node can send a data synchronization request to the target full node, requesting the target full node to synchronize the transaction data of uncached transactions in the specified block of the blockchain.

[0119] When the specified block includes the target block at the target block height requested by the target light node (i.e., when the target light node requests the target full node to synchronize the transaction data of uncached transactions in the target block at the target block height), the target light node can generate a data synchronization request based on its node identifier and the target block height to be synchronized, and send the data synchronization request to the target full node. The target block height can be equal to the height of the highest synchronized block plus 1. When the specified block includes all unsynchronized blocks of the target light node (i.e., when the target light node requests the target full node to synchronize the transaction data of uncached transactions in all unsynchronized blocks), the target light node can generate a data synchronization request based on its node identifier and the heights of all unsynchronized blocks, and send the data synchronization request to the target full node.

[0120] S702, the target full node responds to the data synchronization request by determining the specified block from the blockchain based on the specified block height.

[0121] When the specified block includes the target block at the target block height requested by the target light node for synchronization (i.e., when the target light node requests the target full node to synchronize the transaction data of uncached transactions in the target block at the target block height), the specified block height refers to the target block height. The target full node can determine the target block corresponding to the target block height from the blockchain based on the target block height. When the specified block includes all unsynchronized blocks of the target light node (i.e., when the target light node requests the target full node to synchronize the transaction data of uncached transactions in all unsynchronized blocks), the specified block height refers to the height of all unsynchronized blocks. The target full node can determine all unsynchronized blocks from the blockchain based on the height of all unsynchronized blocks.

[0122] S703, the target full node searches for the transaction identifier of the visible transactions of the target light node in the specified block based on the node identifier of the target light node.

[0123] S704: The target full node obtains the transaction hash of the visible transaction from the specified block based on the transaction identifier of the visible transaction.

[0124] S705, the target full node sends the transaction hash of the visible transactions to the target light node.

[0125] S706, the target light node obtains the transaction hash of the cached transactions in the cache space.

[0126] S707, the target light node filters the transaction hashes of visible transactions based on the transaction hashes of cached transactions in the target light node's cache space to obtain the transaction hashes of uncached transactions of the target light node.

[0127] S708, the target light node sends the transaction hash of the uncached transaction to the target full node.

[0128] S709: The target full node retrieves the transaction data of uncached transactions from the specified block based on the transaction hash of the uncached transactions.

[0129] S710, the target full node synchronizes the transaction data of uncached transactions to the target light node.

[0130] The target full node can synchronize transaction data of uncached transactions to the target light node, and can also synchronize the block header of a specified block to the target light node.

[0131] S711, the target light node stores transaction data for transactions that are not cached.

[0132] The target light node can store transaction data of uncached transactions, block headers of specified blocks, and transaction data of cached transactions in the cache space into the target light node's storage space.

[0133] When the specified block includes the target block corresponding to the target block height requested by the target light node for synchronization, after completing one data synchronization, the highest synchronized block height of the target light node will be updated. The updated highest synchronized block height can be equal to the highest synchronized block height before the update plus 1. If the updated highest synchronized block height is still less than the highest block height of the blockchain, the target full node can continue to send data synchronization requests to the target full node until the updated highest synchronized block height is equal to the highest block height of the blockchain.

[0134] In this embodiment, the process of filtering out the transaction hashes of cached transactions from the transaction hashes of visible transactions in the target light node is performed by the target light node. The target light node can share the data synchronization pressure of the target full node, thereby reducing the data synchronization pressure of the target full node. Furthermore, in the process of determining uncached transactions, the target light node and the target full node transmit the transaction hashes of visible transactions instead of the transaction data of visible transactions, thereby reducing the data synchronization pressure of the target full node by reducing the amount of data transmitted.

[0135] This application proposes a data processing method based on a blockchain network. This method mainly describes the data synchronization process between full nodes and light nodes. Specifically, this data processing method can be executed interactively by any of the aforementioned light nodes (hereinafter referred to as the target light node) and any of the full nodes (hereinafter referred to as the target full node). Figure 8 As shown, the blockchain-based data processing method may include the following steps S501 to S503:

[0136] S801, the target light node sends a data synchronization request to the target full node.

[0137] The target light node can obtain the highest synchronized block height in the target light node and the highest block height of the blockchain. When the highest synchronized block height is less than the highest block height of the blockchain, the target light node can obtain the transaction hash of the cached transactions in the cache space, and generate a data synchronization request based on the node identifier of the target light node, the specified block height requested by the target light node to synchronize, and the transaction hash of the cached transactions, and send the data synchronization request to the target full node.

[0138] Specifically, when the specified block includes the target block at the target block height requested by the target light node for synchronization (i.e., when the target light node requests the target full node to synchronize the transaction data of uncached transactions in the target block at the target block height), the specified block height refers to the target block height. In other words, the target light node can generate a data synchronization request based on its node identifier, the target block height it requests to synchronize, and the transaction hashes of cached transactions. Conversely, when the specified block includes all unsynchronized blocks of the target light node (i.e., when the target light node requests the target full node to synchronize the transaction data of uncached transactions in all unsynchronized blocks), the specified block height refers to the heights of all unsynchronized blocks. In other words, the target light node can generate a data synchronization request based on its node identifier, the heights of all unsynchronized blocks, and the transaction hashes of cached transactions.

[0139] S802, the target full node responds to the data synchronization request by determining the specified block from the blockchain based on the specified block height.

[0140] S803, the target full node searches for the transaction identifier of the visible transactions of the target light node in the specified block based on the node identifier of the target light node.

[0141] S804: The target full node obtains the transaction hash of the visible transaction from the specified block based on the transaction identifier of the visible transaction.

[0142] S805, the target full node filters the transaction hashes of visible transactions based on the transaction hashes of cached transactions to obtain the transaction hashes of uncached transactions of the target light node.

[0143] S806: The target full node retrieves the transaction data of uncached transactions from the specified block based on the transaction hash of the uncached transactions.

[0144] S807, the target full node synchronizes the transaction data of uncached transactions to the target light node.

[0145] The target full node can synchronize transaction data of uncached transactions to the target light node, and can also synchronize the block header of a specified block to the target light node.

[0146] S808, the target light node stores transaction data for transactions that are not cached.

[0147] The target light node can store transaction data of uncached transactions, block headers of specified blocks, and transaction data of cached transactions in the cache space into the target light node's storage space.

[0148] When the specified block includes the target block corresponding to the target block height requested by the target light node for synchronization, after completing one data synchronization, the highest synchronized block height of the target light node will be updated. The updated highest synchronized block height can be equal to the highest synchronized block height before the update plus 1. If the updated highest synchronized block height is still less than the highest block height of the blockchain, the target full node can continue to send data synchronization requests to the target full node until the updated highest synchronized block height is equal to the highest block height of the blockchain.

[0149] Compared to Figure 7 The embodiment shown uses a scheme where the target light node filters the transaction hashes of visible transactions based on the transaction hashes of cached transactions. In this embodiment, the filtering operation is performed by the target full node. This reduces the number of data exchanges between the target full node and the target light node (i.e., the target full node does not need to send the transaction hashes of visible transactions to the target light node, and the target light node does not need to send the transaction hashes of uncached transactions to the target full node), thereby reducing the data synchronization pressure on the target full node.

[0150] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the above solutions of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0151] Please see Figure 9 , Figure 9This is a schematic diagram of the structure of a data processing device based on a blockchain network provided in an embodiment of this application. In one embodiment, the data processing device can be set in the target full node provided in this application embodiment. The data processing device can be a computer program (including program code) running in the target full node, and the data processing device can be used to execute... Figure 4 The corresponding steps in the method embodiments shown may be used to perform... Figure 7 or Figure 8 The steps executed by the target full node in the method embodiment shown are illustrated. Please refer to [link / reference]. Figure 9 The data processing apparatus may include the following units:

[0152] Communication unit 901 is used to receive data synchronization requests sent by target light nodes in the blockchain network;

[0153] Processing unit 902 is used to respond to a data synchronization request by finding the transaction hash of the visible transaction of the target light node in the blockchain. The visible transaction refers to the transaction that the target light node is allowed to access.

[0154] The processing unit 902 is also used to determine the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transaction. The uncached transaction refers to the visible transaction that is not cached in the cache space of the target light node.

[0155] Processing unit 902 is also used to obtain transaction data of uncached transactions from the blockchain based on the transaction hash of the uncached transactions;

[0156] The communication unit 901 is also used to synchronize transaction data of uncached transactions to the target light node for storage.

[0157] In one implementation, when processing unit 902 determines the transaction hash of the uncached transaction of the target light node from the transaction hashes of visible transactions, it specifically performs the following steps:

[0158] The transaction hash of the visible transactions is sent to the target light node; the target light node filters the transaction hash of the visible transactions based on the transaction hash of the cached transactions in the target light node's cache space to obtain the transaction hash of the uncached transactions of the target light node, and sends the transaction hash of the uncached transactions to the target full node;

[0159] Receive the transaction hash of the uncached transaction sent by the target light node.

[0160] In one implementation, the data synchronization request includes the transaction hashes of cached transactions in the cache space of the target light node; the processing unit 902, when determining the transaction hashes of uncached transactions of the target light node from the transaction hashes of visible transactions, specifically performs the following steps:

[0161] Based on the transaction hashes of cached transactions, the transaction hashes of visible transactions are filtered to obtain the transaction hashes of uncached transactions of the target light node.

[0162] In one implementation, the data synchronization request includes the target block height that the target light node is requesting to synchronize;

[0163] Processing unit 902, when searching for the transaction hash of the visible transactions of the target light node in the blockchain, specifically performs the following steps: determining the target block corresponding to the target block height in the blockchain; and searching for the transaction hash of the visible transactions of the target light node in the target block.

[0164] Processing unit 902 is used to retrieve transaction data of uncached transactions from the blockchain based on the transaction hash of the uncached transaction, specifically by performing the following steps: retrieving transaction data of uncached transactions from the target block based on the transaction hash of the uncached transaction.

[0165] In one implementation, the data synchronization request includes the node identifier of the target light node, which is associated with the transaction identifier of the visible transaction; the processing unit 902, when searching for the transaction hash of the visible transaction of the target light node in the blockchain, specifically performs the following steps:

[0166] Based on the node identifier of the target light node, retrieve the transaction identifier of the visible transactions associated with the node identifier of the target light node from the blockchain;

[0167] Based on the transaction identifier of the visible transaction, obtain the transaction hash of the visible transaction of the target light node from the blockchain.

[0168] In one implementation, the communication unit 901 is further configured to perform the following steps: receiving the node identifier of a visible light node sent by the target light node, wherein the visible light node is a light node in the blockchain network set up by the target light node that is allowed to access the target transaction;

[0169] The processing unit 902 is also used to perform the following steps: establish the association between the node identifier of the visible light node and the transaction identifier of the target transaction; and upload the association between the node identifier of the visible light node and the transaction identifier of the target transaction to the blockchain.

[0170] According to another embodiment of this application, Figure 9The data processing device based on a blockchain network shown can be composed of individual or combined units into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the data processing device based on a blockchain network may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0171] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figure 4 The computer program (including program code) for each step involved in the corresponding method shown, or the execution of such... Figure 7 or Figure 8 The corresponding method shown involves computer programs (including program code) for each step of the target full node to construct, as follows: Figure 9 The data processing apparatus based on a blockchain network shown herein, and the data processing method based on a blockchain network for implementing the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0172] In this embodiment, when a full node receives a data synchronization request from a light node, it can synchronize transaction data of transactions visible to the light node but not cached. The light node can store the synchronized transaction data. Visible but uncached transactions refer to transactions that are accessible to the light node but not cached in its cache space. On one hand, the light node in this embodiment supports storing transaction data. After storing the visible but uncached transaction data synchronized by the full node, the light node can directly retrieve the transaction data locally when needed, without requesting the full node again, thus reducing the data synchronization pressure on the full node. On the other hand, the full node synchronizes only the visible but uncached transaction data of the light node, filtering out the cached transaction data in the light node's cache space. This reduces the amount of data synchronized and also alleviates the data synchronization pressure on the full node.

[0173] In another embodiment, the data processing device may be located in the target full node provided in this application embodiment. The data processing device may be a computer program (including program code) running in the target full node, and the data processing device may be used to execute... Figure 5 The corresponding steps in the method embodiments shown may be used to perform... Figure 7 or Figure 8 The steps performed by the target light node in the illustrated method embodiment. Please refer to [link to relevant documentation]. Figure 9 The data processing apparatus may include the following units:

[0174] Communication unit 901 is used to send a data synchronization request to the target full node in the blockchain network; in response to the data synchronization request, the target full node searches for the transaction hash of the visible transactions of the target light node in the blockchain, determines the transaction hash of the uncached transactions of the target light node from the transaction hash of the visible transactions, and returns the transaction data of the uncached transactions based on the transaction hash of the uncached transactions; visible transactions refer to transactions that are allowed to be accessed by the target light node, and uncached transactions refer to visible transactions that are not cached in the cache space of the target light node;

[0175] The communication unit 901 is also used to receive transaction data of unbuffered transactions synchronized by the target full node;

[0176] Processing unit 902 is used to store transaction data for transactions that are not cached.

[0177] In one implementation, the processing unit 902 is further configured to perform the following steps: obtain the target block height and the highest block height of the blockchain that the target light node requests to synchronize; if the target block height is less than or equal to the highest block height, generate a data synchronization request based on the target block height, and trigger the communication unit 901 to perform the step of sending the data synchronization request to the target node in the blockchain network;

[0178] Among them, the transaction hash of the visible transaction and the transaction data of the uncached transaction are obtained by the target full node in the target block corresponding to the target block height.

[0179] In one implementation, the processing unit 902 is further configured to perform the following steps: update the target block height using the target value to obtain the updated target block height;

[0180] If the updated target block height is less than or equal to the highest block height, an updated data synchronization request is generated based on the updated target block height, and data synchronization requests are continued to be sent to the target full node based on the updated data synchronization request until the updated target block height is greater than the highest block height.

[0181] In one implementation, the communication unit 901 is further configured to perform the following steps: receiving a transaction request for a target transaction sent by a client, and forwarding the transaction request for the target transaction to the target full node; the target full node responds to the transaction request, executes the target transaction, generates and returns the transaction execution result of the target transaction, the transaction execution result including the transaction hash of the target transaction; and receives the transaction execution result of the target transaction.

[0182] The processing unit 902 is also configured to perform the following steps: generate transaction data of the target transaction based on the transaction execution result and the transaction request of the target transaction, and cache the transaction data of the target transaction in the cache space of the target light node;

[0183] The communication unit 901 is also used to perform the following steps: forwarding the transaction execution result of the target transaction to the client.

[0184] In one implementation, the processing unit 902 is further configured to perform the following steps: when the cache cleanup conditions are met, delete the transaction data of the cached transactions in the cache space of the target light node;

[0185] The cache cleanup conditions include: the target light node's cache space reaching the cache limit, and the end time of the cache cycle being reached.

[0186] According to another embodiment of this application, Figure 9 The data processing device based on a blockchain network shown can be composed of individual or combined units into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the data processing device based on a blockchain network may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0187] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figure 5 The computer program (including program code) for each step involved in the corresponding method shown, or the execution of such... Figure 7 or Figure 8 The corresponding method shown involves computer programs (including program code) for each step of the target light node to construct, as... Figure 9The data processing apparatus based on a blockchain network shown herein, and the data processing method based on a blockchain network for implementing the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0188] In this embodiment, a light node can send a data synchronization request to a full node, requesting the synchronization of transaction data that is visible to the light node but not cached from the full node. The light node can then store the transaction data synchronized by the full node. Here, "visible but not cached transactions" refers to transactions that are accessible to the light node but not cached in its cache space. On one hand, the light node in this embodiment supports storing transaction data. After storing the visible but not cached transaction data synchronized by the full node, the light node can directly retrieve the transaction data locally when needed, without requesting the full node again, thus reducing the data synchronization pressure on the full node. On the other hand, the full node synchronizes only the visible but not cached transaction data of the light node, filtering out the cached transaction data in the light node's cache space. This reduces the amount of data synchronized and also alleviates the data synchronization pressure on the full node.

[0189] Based on the above methods and apparatus embodiments, this application provides a computer device based on a blockchain network, which can be the aforementioned target full node or target light node. Please refer to... Figure 10 , Figure 10 This is a schematic diagram of the structure of a computer device based on a blockchain network provided in an embodiment of this application. Figure 10 The computer device shown includes at least a processor 1001, an input interface 1002, an output interface 1003, and a computer-readable storage medium 1004. The processor 1001, input interface 1002, output interface 1003, and computer-readable storage medium 1004 can be connected via a bus or other means.

[0190] When the computer device is the target full node, input interface 1002 can be used to receive data synchronization requests, receive transaction hashes of uncached transactions, etc.; output interface 1003 can be used to send transaction hashes of visible transactions, send transaction data of uncached transactions, etc. When the computer device is the target light node, input interface 1002 can be used to receive transaction hashes of visible transactions, receive transaction data of uncached transactions, etc.; output interface 1003 can be used to send data synchronization requests, send transaction hashes of uncached transactions, etc.

[0191] The computer-readable storage medium 1004 can be stored in the memory of a computer device. The computer-readable storage medium 1004 is used to store computer programs, including computer instructions. The processor 1001 is used to execute the program instructions stored in the computer-readable storage medium 1004. The processor 1001 (or CPU (Central Processing Unit)) is the computing and control core of the computer device, suitable for implementing one or more computer instructions, specifically suitable for loading and executing one or more computer instructions to achieve corresponding method flows or corresponding functions.

[0192] This application also provides a computer-readable storage medium (Memory), which is a memory device in a computer device used to store programs and data. It is understood that the computer-readable storage medium here can include both built-in storage media in the computer device and extended storage media supported by the computer device. The computer-readable storage medium provides storage space that stores the operating system of the computer device. Furthermore, the storage space also stores one or more computer instructions suitable for loading and execution by a processor. These computer instructions can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0193] In one embodiment, the processor 1001 may load and execute one or more computer instructions stored in the computer-readable storage medium 1004 to implement the aforementioned related... Figure 4 The corresponding steps of the data processing method based on the blockchain network shown, or the implementation of the above-mentioned related steps. Figure 7 or Figure 8 The corresponding steps of the target full node in the data processing method based on the blockchain network are shown. Specifically, the computer instructions in the computer-readable storage medium 1004 are loaded by the processor 1001 and executed as follows:

[0194] Receive data synchronization requests sent by target light nodes in the blockchain network;

[0195] In response to a data synchronization request, find the transaction hash of the visible transactions of the target light node in the blockchain. Visible transactions are those that the target light node is allowed to access.

[0196] Determine the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transactions. The uncached transaction refers to the visible transaction that is not cached in the cache space of the target light node.

[0197] Retrieve transaction data of uncached transactions from the blockchain based on the transaction hash of the uncached transactions;

[0198] Synchronize the transaction data of uncached transactions to the target light node for storage.

[0199] In one implementation, when the computer instructions in the computer-readable storage medium 1004 are loaded and executed by the processor 1001 to determine the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transactions, they are specifically used to perform the following steps:

[0200] The transaction hash of the visible transactions is sent to the target light node; the target light node filters the transaction hash of the visible transactions based on the transaction hash of the cached transactions in the target light node's cache space to obtain the transaction hash of the uncached transactions of the target light node, and sends the transaction hash of the uncached transactions to the target full node;

[0201] Receive the transaction hash of the uncached transaction sent by the target light node.

[0202] In one implementation, the data synchronization request includes the transaction hashes of cached transactions in the target light node's cache space; when the computer instructions in the computer-readable storage medium 1004 are loaded and executed by the processor 1001 to determine the transaction hashes of uncached transactions in the target light node from the transaction hashes of visible transactions, they are specifically used to perform the following steps:

[0203] Based on the transaction hashes of cached transactions, the transaction hashes of visible transactions are filtered to obtain the transaction hashes of uncached transactions of the target light node.

[0204] In one implementation, the data synchronization request includes the target block height that the target light node is requesting to synchronize;

[0205] When the computer instructions in the computer-readable storage medium 1004 are loaded and executed by the processor 1001 to find the transaction hash of the visible transactions of the target light node in the blockchain, they are specifically used to perform the following steps: determine the target block corresponding to the target block height in the blockchain; and find the transaction hash of the visible transactions of the target light node in the target block.

[0206] When the computer instructions in the computer-readable storage medium 1004 are loaded and executed by the processor 1001 to retrieve transaction data of an uncached transaction from the blockchain based on the transaction hash of the uncached transaction, they are specifically used to perform the following steps: retrieve transaction data of an uncached transaction from the target block based on the transaction hash of the uncached transaction.

[0207] In one implementation, the data synchronization request includes the node identifier of the target light node, which is associated with the transaction identifier of the visible transaction. When the computer instructions in the computer-readable storage medium 1004 are loaded and executed by the processor 1001 to find the transaction hash of the visible transaction of the target light node in the blockchain, they are specifically used to perform the following steps:

[0208] Based on the node identifier of the target light node, retrieve the transaction identifier of the visible transactions associated with the node identifier of the target light node from the blockchain;

[0209] Based on the transaction identifier of the visible transaction, obtain the transaction hash of the visible transaction of the target light node from the blockchain.

[0210] In one implementation, the computer instructions in the computer-readable storage medium 1004 are loaded by the processor 1001 and are also used to perform the following steps:

[0211] Receive the node identifier of the visible light node sent by the target light node. The visible light node is a light node in the blockchain network set up by the target light node that is allowed to access the target transaction.

[0212] Establish the association between the node identifier of the visible light node and the transaction identifier of the target transaction; upload the association between the node identifier of the visible light node and the transaction identifier of the target transaction to the blockchain.

[0213] In this embodiment, when a full node receives a data synchronization request from a light node, it can synchronize transaction data of transactions visible to the light node but not cached. The light node can store the synchronized transaction data. Visible but uncached transactions refer to transactions that are accessible to the light node but not cached in its cache space. On one hand, the light node in this embodiment supports storing transaction data. After storing the visible but uncached transaction data synchronized by the full node, the light node can directly retrieve the transaction data locally when needed, without requesting the full node again, thus reducing the data synchronization pressure on the full node. On the other hand, the full node synchronizes only the visible but uncached transaction data of the light node, filtering out the cached transaction data in the light node's cache space. This reduces the amount of data synchronized and also alleviates the data synchronization pressure on the full node.

[0214] In another embodiment, the processor 1001 may load and execute one or more computer instructions stored in the computer-readable storage medium 1004 to implement the aforementioned related... Figure 5 The corresponding steps of the data processing method based on the blockchain network shown, or the implementation of the above-mentioned related steps. Figure 7 or Figure 8 The corresponding steps of the target light node in the data processing method based on the blockchain network are shown. Specifically, the computer instructions in the computer-readable storage medium 1004 are loaded by the processor 1001 and executed as follows:

[0215] A data synchronization request is sent to the target full node in the blockchain network. In response to the data synchronization request, the target full node searches for the transaction hash of the visible transactions of the target light node in the blockchain, determines the transaction hash of the uncached transactions of the target light node from the transaction hash of the visible transactions, and returns the transaction data of the uncached transactions based on the transaction hash of the uncached transactions. Visible transactions refer to transactions that are allowed to be accessed by the target light node, and uncached transactions refer to visible transactions that are not cached in the cache space of the target light node.

[0216] Receive transaction data of uncached transactions synchronized by the target full node;

[0217] Store transaction data for transactions that are not cached.

[0218] In one implementation, the computer instructions in the computer-readable storage medium 1004 are loaded by the processor 1001 and are also used to perform the following steps:

[0219] Obtain the target block height and the highest block height of the blockchain that the target light node is requesting to synchronize;

[0220] If the target block height is less than or equal to the highest block height, a data synchronization request is generated based on the target block height, and the step of sending a data synchronization request to the target node in the blockchain network is triggered.

[0221] Among them, the transaction hash of the visible transaction and the transaction data of the uncached transaction are obtained by the target full node in the target block corresponding to the target block height.

[0222] In one implementation, the computer instructions in the computer-readable storage medium 1004 are loaded by the processor 1001 and are also used to perform the following steps:

[0223] The target block height is updated using the target value to obtain the updated target block height;

[0224] If the updated target block height is less than or equal to the highest block height, an updated data synchronization request is generated based on the updated target block height, and data synchronization requests are continued to be sent to the target full node based on the updated data synchronization request until the updated target block height is greater than the highest block height.

[0225] In one implementation, the computer instructions in the computer-readable storage medium 1004 are loaded by the processor 1001 and are also used to perform the following steps:

[0226] Receives a transaction request for the target transaction sent by the client and forwards the transaction request to the target full node; the target full node responds to the transaction request, executes the target transaction, generates and returns the transaction execution result of the target transaction, which includes the transaction hash of the target transaction; receives the transaction execution result of the target transaction;

[0227] The transaction data of the target transaction is generated based on the transaction execution result and the transaction request of the target transaction, and the transaction data of the target transaction is cached in the cache space of the target light node.

[0228] Forward the transaction execution result of the target transaction to the client.

[0229] In one implementation, the computer instructions in the computer-readable storage medium 1004 are loaded by the processor 1001 and are also used to perform the following steps: when the cache cleanup conditions are met, delete the transaction data of cached transactions in the cache space of the target light node;

[0230] The cache cleanup conditions include: the target light node's cache space reaching the cache limit, and the end time of the cache cycle being reached.

[0231] In this embodiment, a light node can send a data synchronization request to a full node, requesting the synchronization of transaction data that is visible to the light node but not cached from the full node. The light node can then store the transaction data synchronized by the full node. Here, "visible but not cached transactions" refers to transactions that are accessible to the light node but not cached in its cache space. On one hand, the light node in this embodiment supports storing transaction data. After storing the visible but not cached transaction data synchronized by the full node, the light node can directly retrieve the transaction data locally when needed, without requesting the full node again, thus reducing the data synchronization pressure on the full node. On the other hand, the full node synchronizes only the visible but not cached transaction data of the light node, filtering out the cached transaction data in the light node's cache space. This reduces the amount of data synchronized and also alleviates the data synchronization pressure on the full node.

[0232] According to one aspect of this application, a computer program product or computer program is provided, comprising 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 blockchain-based data processing method provided in the various alternative embodiments described above.

[0233] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data processing method based on a blockchain network, characterized in that, The blockchain network includes multiple nodes, which include light nodes or full nodes, and the method is executed by a target full node in the blockchain network; the method includes: Receive a data synchronization request sent by a target light node in the blockchain network, wherein the data synchronization request includes the target block height that the target light node requests to synchronize; In response to the data synchronization request, a target block corresponding to the target block height is determined in the blockchain. The transaction hash of the visible transactions of the target light node is searched in the target block. The visible transactions refer to transactions that the target light node is allowed to access. The visible transactions include transactions that the target light node designates to be visible to itself, as well as transactions that other light nodes in the blockchain network, excluding the target light node, designate to be visible to the target light node. The transaction hash of the uncached transaction of the target light node is determined from the transaction hash of the visible transactions, wherein the uncached transaction refers to the visible transaction that is not cached in the cache space of the target light node; Based on the transaction hash of the uncached transaction, the transaction data of the uncached transaction is obtained from the target block, and the transaction data of the uncached transaction is synchronized to the target light node for storage.

2. The method as described in claim 1, characterized in that, Determining the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transactions includes: The transaction hash of the visible transactions is sent to the target light node; the target light node filters the transaction hash of the visible transactions based on the transaction hash of the cached transactions in the target light node's cache space to obtain the transaction hash of the uncached transactions of the target light node, and sends the transaction hash of the uncached transactions to the target full node; Receive the transaction hash of the uncached transaction sent by the target light node.

3. The method as described in claim 1, characterized in that, The data synchronization request includes the transaction hashes of cached transactions in the cache space of the target light node; determining the transaction hashes of uncached transactions of the target light node from the transaction hashes of the visible transactions includes: Based on the transaction hash of the cached transactions, the transaction hash of the visible transactions is filtered to obtain the transaction hash of the uncached transactions of the target light node.

4. The method as described in claim 1, characterized in that, The node identifier of the target light node is associated with the transaction identifier of the visible transaction; the step of searching for the transaction hash of the visible transaction of the target light node in the target block includes: Based on the node identifier of the target light node, obtain the transaction identifier of the visible transaction associated with the node identifier of the target light node from the target block; Based on the transaction identifier of the visible transaction, obtain the transaction hash of the visible transaction of the target light node from the target block.

5. The method as described in claim 1, characterized in that, The method further includes: Receive the node identifier of the visible light node sent by the target light node, wherein the visible light node is a light node in the blockchain network set by the target light node that is allowed to access the target transaction; Establish the association between the node identifier of the visible light node and the transaction identifier of the target transaction; The association between the node identifier of the visible light node and the transaction identifier of the target transaction is uploaded to the blockchain.

6. A data processing method based on a blockchain network, characterized in that, The blockchain network includes multiple nodes, which include light nodes or full nodes, and the method is executed by a target light node in the blockchain network; the method includes: A data synchronization request is sent to a target full node in the blockchain network. The data synchronization request includes the target block height that the target light node requests to synchronize. In response to the data synchronization request, the target full node determines the target block corresponding to the target block height in the blockchain, searches for the transaction hash of the visible transactions of the target light node in the target block, determines the transaction hash of the uncached transactions of the target light node from the transaction hash of the visible transactions, and retrieves the transaction data of the uncached transactions from the target block based on the transaction hash of the uncached transactions. Visible transactions refer to transactions that the target light node is allowed to access, and uncached transactions refer to visible transactions that are not cached in the cache space of the target light node. Visible transactions include transactions that the target light node designates to be visible to itself, and transactions that other light nodes in the blockchain network, excluding the target light node, designate to be visible to the target light node. Receive the transaction data of the uncached transactions synchronized by the target full node, and store the transaction data of the uncached transactions.

7. The method as described in claim 6, characterized in that, The method further includes: Obtain the target block height requested for synchronization by the target light node and the highest block height of the blockchain; If the target block height is less than or equal to the highest block height, then the data synchronization request is generated based on the target block height, and the step of sending the data synchronization request to the target full node in the blockchain network is triggered. The transaction hash of the visible transaction and the transaction data of the uncached transaction are obtained by the target full node from the target block corresponding to the target block height.

8. The method as described in claim 7, characterized in that, After receiving the transaction data of the uncached transactions synchronized by the target full node, the method further includes: The target block height is updated using the target value to obtain the updated target block height; If the updated target block height is less than or equal to the highest block height, an updated data synchronization request is generated based on the updated target block height, and data synchronization requests are continued to be sent to the target full node based on the updated data synchronization request until the updated target block height is greater than the highest block height.

9. The method as described in claim 6, characterized in that, The method further includes: The system receives a transaction request for a target transaction from a client and forwards the transaction request to the target full node. The target full node responds to the transaction request, executes the target transaction, generates and returns the transaction execution result of the target transaction, and the transaction execution result includes the transaction hash of the target transaction. Receive the transaction execution result of the target transaction; Based on the transaction execution result and the transaction request of the target transaction, the transaction data of the target transaction is generated, the transaction data of the target transaction is cached in the cache space of the target light node, and the transaction execution result of the target transaction is forwarded to the client.

10. The method as described in claim 6, characterized in that, The method further includes: When the cache cleanup conditions are met, the transaction data of the cached transactions in the cache space of the target light node are deleted; The cache cleanup conditions include: the target light node's cache space reaching the cache limit, and the end time of the cache cycle being reached.

11. A data processing device based on a blockchain network, characterized in that, The blockchain network includes multiple nodes, which include light nodes or full nodes, and the data processing device is located in a target full node of the blockchain network; the data processing device includes: A communication unit is configured to receive a data synchronization request sent by a target light node in the blockchain network, wherein the data synchronization request includes the target block height that the target light node requests to synchronize. The processing unit is configured to, in response to the data synchronization request, determine the target block corresponding to the target block height in the blockchain, and search for the transaction hash of the visible transactions of the target light node in the target block. The visible transactions refer to transactions that the target light node is allowed to access. The visible transactions include transactions that the target light node designates to be visible to itself, as well as transactions that other light nodes in the blockchain network, excluding the target light node, designate to be visible to the target light node. The processing unit is further configured to determine the transaction hash of the uncached transaction of the target light node from the transaction hash of the visible transaction, wherein the uncached transaction refers to the visible transaction that is not cached in the cache space of the target light node; The processing unit is further configured to obtain the transaction data of the uncached transaction from the target block based on the transaction hash of the uncached transaction; The communication unit is also used to synchronize the transaction data of the uncached transactions to the target light node for storage.

12. A data processing device based on a blockchain network, characterized in that, The blockchain network includes multiple nodes, which include light nodes or full nodes, and the data processing device is installed in the target light node of the blockchain network. The data processing device includes: A communication unit is configured to send a data synchronization request to a target full node in the blockchain network. The data synchronization request includes the target block height that the target light node requests to synchronize. In response to the data synchronization request, the target full node determines the target block corresponding to the target block height in the blockchain, searches for the transaction hash of the visible transactions of the target light node in the target block, determines the transaction hash of the uncached transactions of the target light node from the transaction hash of the visible transactions, and obtains the transaction data of the uncached transactions from the target block based on the transaction hash of the uncached transactions. Visible transactions refer to transactions that the target light node is allowed to access, and uncached transactions refer to visible transactions that are not cached in the cache space of the target light node. Visible transactions include transactions that the target light node designates to be visible to itself, and transactions that other light nodes in the blockchain network, excluding the target light node, designate to be visible to the target light node. The communication unit is also used to receive transaction data of the uncached transaction synchronized by the target full node; The processing unit is used to store the transaction data of the uncached transactions.

13. A computer device based on a blockchain network, characterized in that, The blockchain network includes multiple nodes, which include light nodes or full nodes, and the computer device is a target full node or a target light node in the blockchain network; the computer device includes: A processor is a tool for implementing computer programs. A computer-readable storage medium storing a computer program adapted to be loaded by the processor and execute the data processing method based on a blockchain network as described in any one of claims 1 to 5, or to execute the data processing method based on a blockchain network as described in any one of claims 6 to 10.

14. 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 executed by the data processing method based on a blockchain network as described in any one of claims 1 to 5, or by executing the data processing method based on a blockchain network as described in any one of claims 6 to 10.

15. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the data processing method based on a blockchain network as described in any one of claims 1 to 5, or perform the data processing method based on a blockchain network as described in any one of claims 6 to 10.

Images