Block chain-based data processing method and related device

Abstract

The invention provides a block chain-based data processing method and a related device. The embodiment of the invention can be applied to various scenes such as block chains. The method comprises the steps that a target digital asset is transferred from a transaction address of a first node to a transaction address of a second node based on a transaction instruction, and the second node generates a verification request of state change of the target digital asset according to identification information of the target digital asset and sends the verification request to a verification server, the verification server verifies the state change of the target digital assets and sends a current state change verification result to the second node, the second node receives the current state change verification result and verifies the target digital assets of the second node, and in the receiving verification stage of the target digital assets, the current state change verification result is sent to the verification server; the current state change condition of the target digital asset is verified through the verification server of the third party, so that the acceptance cost and verification cost of a receiver on all preposed transactions of the target digital asset are reduced.

Description

Technical Field

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

[0002] Unspent Transaction Output (UTXO) is an important concept in blockchain. It refers to digital assets or other cryptocurrencies that have been traded on the blockchain but have not yet been spent again.

[0003] The current digital asset model uses the UTXO model, which supports decentralized transfers by users without the need for third-party intervention. However, it cannot support smart contracts based on state models, which limits the expansion of business scenarios on digital asset systems.

[0004] UTXO blockchain one-time encapsulation technology is considered an effective technique to improve the scalability of UTXO blockchains such as digital assets. Even with the adoption of UTXO blockchain one-time encapsulation technology to expand the functionality of digital asset systems and enable smart contracts with runtime state models, this technology requires the recipient to fully accept and compute all the preceding transactions of the accepted UTXO one-time encapsulation, resulting in high verification costs at the recipient's end. For the sender of the UTXO one-time encapsulation, it needs to constantly hold and safeguard all the preceding transactions of its assets, leading to high storage costs. Therefore, existing UTXO blockchain one-time encapsulation technology incurs significant cost losses for both the recipient and the sender. Summary of the Invention

[0005] This application provides a blockchain-based data processing method and related apparatus. By storing all the previous transactions of the target digital asset in a third-party verification server, the method provides the recipient of the target digital asset transfer with verification of the state changes of the target digital asset, thereby reducing the recipient's acceptance cost and verification cost for all previous transactions of the target digital asset.

[0006] One aspect of this application provides a blockchain-based data processing method, comprising:

[0007] Based on the transaction instructions, the target digital asset is transferred from the transaction address of the first node to the transaction address of the second node, and the state change information of the target digital asset is recorded in the blockchain. The state change information of the target digital asset is used to represent the transfer of the target digital asset from the transaction address of the first node to the transaction address of the second node.

[0008] A verification request for a change in the state of the target digital asset is generated based on the identification information of the target digital asset. The verification request for a change in the state of the target digital asset carries the identification information of the target digital asset.

[0009] The verification request for the state change of the target digital asset is sent to the verification server. The verification server is used to obtain the transfer path of the target digital asset based on the identification information of the target digital asset, verify the state change of the target digital asset based on the transfer path of the target digital asset, and generate the current state change verification result. The transfer path is used to represent the transaction information and state change information of the target digital asset in M ​​transactions, where M is an integer greater than or equal to 1.

[0010] Receive the current state change verification result. If the current state change verification result indicates that the state change of the target digital asset was successful, verify the digital asset of the second node.

[0011] Another aspect of this application provides a blockchain-based data processing apparatus, comprising:

[0012] The current transaction information module is used to transfer the target digital asset from the transaction address of the first node to the transaction address of the second node based on the transaction instruction, and to record the state change information of the target digital asset in the blockchain. The state change information of the target digital asset is used to represent the transfer of the target digital asset from the transaction address of the first node to the transaction address of the second node.

[0013] The status change verification request module is used to generate a verification request for a status change of the target digital asset based on the identification information of the target digital asset. The verification request for the status change of the target digital asset carries the identification information of the target digital asset.

[0014] The verification request sending module is used to send the verification request for the state change of the target digital asset to the verification server. The verification server is used to obtain the transfer path of the target digital asset based on the identification information of the target digital asset, verify the state change information of the target digital asset based on the transfer path, and generate the current state change verification result. The transfer path is used to represent the transaction information and state change information of the target digital asset in M ​​transactions, where M is an integer greater than or equal to 1.

[0015] The digital asset verification module is used to receive the current state change verification result. If the current state change verification result indicates that the state change of the target digital asset is successful, the module verifies the digital asset of the second node.

[0016] In another implementation of this application's embodiments, the verification server is further used for:

[0017] The transfer path of the target digital asset is analyzed to obtain M preceding transaction information and M preceding status change information of the target digital asset;

[0018] Based on M prior transaction information and M prior state change information of the target digital asset, the state change information of the target digital asset is verified, and the current state change verification result is generated.

[0019] In another implementation of this application's embodiments, the verification server is further used for:

[0020] If the M preceding state change information includes the state change information of the target digital asset, then the current state change verification result is successful.

[0021] If the M preceding state change information does not include the state change information of the target digital asset, then the current state change verification result is verification failure.

[0022] In another implementation of this application's embodiments, the digital asset verification module is further used for:

[0023] Receive the most recent transaction information from among M previous transaction information, and obtain the digital asset holding information of the second node;

[0024] The digital assets actually held by the second node are verified based on the most recent previous transaction information and the digital asset holding information of the second node.

[0025] In another implementation of this application's embodiments, the digital asset verification module is further used for:

[0026] Based on the most recent previous transaction information and the digital asset holding information of the second node, generate the digital asset holding value of the second node;

[0027] If the digital asset holding value of the second node is equal to the actual digital asset holding value of the second node, a message indicating successful verification of the actual digital asset holding of the second node is generated.

[0028] If the digital asset holding value of the second node is not equal to the actual digital asset value held by the second node, a message indicating that the verification of the actual digital asset held by the second node has failed will be generated.

[0029] In another implementation of this application's embodiments, the current transaction information module is further used for:

[0030] Based on the identification information of the target digital asset, a transfer path request for the target digital asset is generated, wherein the transfer path request for the target digital asset carries the identification information of the target digital asset.

[0031] The transfer path request of the target digital asset is sent to the verification server, whereby the verification server is used to obtain the transfer path of the target digital asset based on the transfer path request.

[0032] Receive the transfer path of the target digital asset, verify the digital asset of the first node according to the transfer path of the target digital asset, and if the target digital asset is included in the digital asset of the first node, generate a transaction instruction based on the transaction address of the first node, the transaction address of the second node and the target digital asset.

[0033] In another implementation of this application's embodiments, the current transaction information module is further used for:

[0034] Obtain M prior transaction information of the target digital asset, where M is an integer greater than or equal to 1;

[0035] Serialize the M preceding transaction information to generate the transfer path of the target digital asset.

[0036] In another implementation of this application's embodiments, the current transaction information module is further used for:

[0037] The transfer path of the target digital asset is analyzed to obtain M prior transaction information of the target digital asset;

[0038] The first node verifies the inclusion of the target digital asset in the target digital asset based on M prior transaction information of the target digital asset.

[0039] In another implementation of this application's embodiments, the current transaction information module is further used for:

[0040] If the most recent transaction among the M preceding transaction records of the target digital asset indicates that the receiving address of the target digital asset is the transaction address of the first node, then the digital assets of the first node include the target digital asset.

[0041] If the most recent transaction among the M preceding transaction records of the target digital asset indicates that the receiving address of the target digital asset is not the transaction address of the first node, then the target digital asset is not included in the digital assets of the first node.

[0042] In another implementation of this application's embodiments, the blockchain-based data processing device further includes a billing module; specifically, the billing module is used for:

[0043] Based on the verification request for the state change of the target digital asset, first billing information is generated, wherein the first billing information is used to characterize the cost statistics of the verification server for the verification request for the state change of the target digital asset of the second node.

[0044] Based on the transfer path request of the target digital asset, a second billing information is generated, wherein the second billing information is used to characterize the cost statistics of the transfer path request of the target digital asset of the first node by the verification server.

[0045] In the blockchain-based data processing method provided in this application, the verification server is used to perform:

[0046] Receive a verification request for a state change of the target digital asset sent by the second node, wherein the verification request for a state change of the target digital asset carries the identification information of the target digital asset;

[0047] Obtain the transfer path of the target digital asset based on its identification information;

[0048] The state change of the target digital asset is verified based on its transfer path, and the current state change verification result is generated.

[0049] Send the current state change verification result to the second node.

[0050] The blockchain-based data processing device provided in this application further includes:

[0051] The state change verification request receiving module is used to receive the state change verification request of the target digital asset sent by the second node, wherein the state change verification request of the target digital asset carries the identification information of the target digital asset.

[0052] The transfer path acquisition module is used to acquire the transfer path of the target digital asset based on the identification information of the target digital asset.

[0053] The status change verification module is used to verify the status change of the target digital asset based on the transfer path of the target digital asset and generate the current status change verification result.

[0054] The status change verification result sending module is used to send the current status change verification result to the second node.

[0055] In another implementation of the embodiments of this application, the blockchain-based data processing device further includes:

[0056] The target digital asset verification request receiving module is also used to receive the verification request of the second node's digital asset sent by the second node, wherein the verification request of the second node's digital asset carries the identification information of the target digital asset and the identification information of the second node.

[0057] The target digital asset information acquisition module is used to obtain the current status information of the target digital asset based on the identification information of the target digital asset, and to obtain the digital asset holding information of the second node based on the identification information of the second node.

[0058] The target digital asset information sending module is used to send the current status information and the digital asset holding information of the second node to the second node.

[0059] In another implementation of the embodiments of this application, the blockchain-based data processing device further includes:

[0060] The transfer path request receiving module is used to receive the transfer path request of the target digital asset sent by the first node, wherein the transfer path request of the target digital asset carries the identification information of the target digital asset.

[0061] The transfer path acquisition module is also used to acquire the transfer path of the target digital asset based on the transfer path request of the target digital asset;

[0062] The transfer path sending module is used to send the transfer path of the target digital asset to the first node.

[0063] Another aspect of this application provides a computer device, comprising:

[0064] Memory, transceiver, processor, and bus system;

[0065] The memory is used to store programs;

[0066] The processor is used to execute programs in memory, including methods for performing the aspects mentioned above;

[0067] Bus systems are used to connect memory and processor to enable communication between them.

[0068] Another aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the methods described above.

[0069] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the above aspects.

[0070] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0071] This application provides a blockchain-based data processing method and related apparatus. The method includes: transferring a target digital asset from the transaction address of a first node to the transaction address of a second node based on a transaction instruction, and recording the state change information of the target digital asset in the blockchain; the second node generating a verification request for the state change of the target digital asset based on the identification information of the target digital asset; the second node sending the verification request for the state change of the target digital asset to a verification server; the verification server obtaining the transfer path of the target digital asset based on the identification information of the target digital asset, verifying the state change of the target digital asset based on the transfer path, generating a current state change verification result, and sending the current state change verification result to the second node; the second node receiving the current state change verification result and determining the state change of the target digital asset based on the current state change verification result. In a more successful scenario, the digital assets of the second node are verified by storing the transfer paths of transaction information and state change information representing the entire transaction process of the target digital asset in a third-party verification server. During the target digital asset reception and verification phase, the second node, as the recipient of the target digital asset, does not need to accept the transfer paths of all the previous transactions of the target digital asset. The second node generates a verification request for the state change of the target digital asset based on the identification information of the target digital asset and sends it to the third-party verification server. The third-party verification server verifies the current state change of the target digital asset. The second node, as the recipient of the target digital asset, only needs to receive the state change result of the target digital asset, which reduces the cost for the recipient to accept and verify all transaction information and state change information of the target digital asset. Attached Figure Description

[0072] Figure 1 This is a schematic diagram of the structure of a data sharing system provided in one embodiment of this application;

[0073] Figure 2 This is a schematic diagram of the structure of a blockchain provided in one embodiment of this application;

[0074] Figure 3 A schematic diagram illustrating the block generation process provided in a certain embodiment of this application;

[0075] Figure 4 A flowchart illustrating a blockchain-based data processing method provided in one embodiment of this application;

[0076] Figure 5 A timing diagram of a blockchain-based data processing method provided in one embodiment of this application;

[0077] Figure 6 A schematic diagram illustrating a blockchain-based data processing method provided in one embodiment of this application;

[0078] Figure 7 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0079] Figure 8 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0080] Figure 9 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0081] Figure 10 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0082] Figure 11 A schematic diagram illustrating a blockchain-based data processing method provided in one embodiment of this application;

[0083] Figure 12 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0084] Figure 13 A timing diagram of a blockchain-based data processing method provided in one embodiment of this application;

[0085] Figure 14 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0086] Figure 15 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0087] Figure 16 A schematic diagram illustrating a blockchain-based data processing method provided in one embodiment of this application;

[0088] Figure 17 An application environment diagram of a blockchain data processing method provided in one embodiment of this application;

[0089] Figure 18 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0090] Figure 19 A flowchart illustrating a blockchain-based data processing method provided in another embodiment of this application;

[0091] Figure 20 A flowchart illustrating a blockchain-based data processing method provided in yet another embodiment of this application;

[0092] Figure 21A schematic diagram of the structure of a blockchain-based data processing device provided in one embodiment of this application;

[0093] Figure 22 A schematic diagram of the structure of a blockchain-based data processing device provided in another embodiment of this application;

[0094] Figure 23 This is a schematic diagram of a server structure provided in one embodiment of this application. Detailed Implementation

[0095] This application provides a blockchain-based data processing method. By storing the transfer paths of transaction information and state change information representing the entire transaction process of a target digital asset in a third-party verification server, during the target digital asset reception and verification stage, the second node, as the recipient of the target digital asset, does not need to accept the transfer paths of all previous transactions of the target digital asset. Instead, it verifies the current state change of the target digital asset through the third-party verification server. The second node, as the recipient of the target digital asset, only needs to receive the state change results of the target digital asset, thereby reducing the reception cost and verification cost of all transaction information and state change information of the target digital asset.

[0096] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “corresponding to,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0097] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0098] This application relates to the field of blockchain technology.

[0099] It is understood that in the specific implementation of this application, data related to blockchain data, transaction data, user information, etc. are involved. When the above data is used in specific products or technologies in the embodiments of this application, user permission or consent is required. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0100] To facilitate understanding of the technical solutions provided in the embodiments of this application, some key terms used in the embodiments of this application will be explained below:

[0101] Blockchain: A data structure consisting of several blocks linked together by hash values. Each block consists of transactions generated within a certain period of time, packaged by computer nodes that have the right to record transactions, and independently verified by each computer node.

[0102] Blockchain technology: Blockchain technology is a new distributed infrastructure and computing paradigm that uses a block-chain data structure to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script code to program and manipulate data.

[0103] Full node: refers to a complete node that maintains the blockchain, capable of independently packaging and verifying transactions, and handling client requests to read and write smart contract states.

[0104] Unspent Transaction Output (UTXO): This is a blockchain transaction model widely used in blockchains such as those for digital assets. It refers to a transaction that will spend a certain output and generate an unspent output for use in the next transaction, thereby ensuring the constant total amount of digital assets in the system.

[0105] UTXO cluster: This refers to a cluster formed by multiple computers that maintain the state of UTXOs in the blockchain nodes. The UTXOs of each machine in a single cluster are unique (i.e., the UTXOs of each machine in a single cluster correspond to different transactions). Multiple UTXO clusters maintain the same blockchain. The main UTXO blockchain cluster corresponds to the main blockchain node of this application; the same-city UTXO blockchain cluster corresponds to the same-city blockchain backup node of this application; and the off-site UTXO blockchain cluster corresponds to the off-site blockchain backup node of this application.

[0106] One-time encapsulation, also known as "one-time sealing," refers to a technique where a state change is attached to a specific UTXO, and subsequent state changes require the UTXO to confirm the uniqueness of each subsequent state change. Typical UTXO one-time encapsulation protocols include the RGB protocol for digital assets.

[0107] 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 data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0108] The underlying blockchain platform can include modules for user management, basic services, smart contracts, and operations. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user identities and blockchain addresses (access management). Under authorization, it also monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information using a consensus algorithm (consensus). The management module (network communication) ensures that the encrypted data is transmitted completely and consistently to the shared ledger and recorded. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, the module calls keys or other events to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operations module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time visualization of the product's running status during product release, such as alarms, network status updates, and node device health status updates.

[0109] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0110] See Figure 1The data sharing system shown, data sharing system 100, refers to a system for data sharing between nodes. This data sharing system may include multiple nodes 101, which can refer to various clients within the data sharing system. Each node 101, during normal operation, can receive input information and maintain shared data within the data sharing system based on the received input information. To ensure information interoperability within the data sharing system, information connections can exist between each node, allowing information transmission between nodes. For example, when any node in the data sharing system receives input information, other nodes in the system obtain this input information according to a consensus algorithm and store it as data in the shared data, ensuring consistency of data stored on all nodes in the data sharing system.

[0111] Each node in the data sharing system has a corresponding node identifier, and each node can also store the node identifiers of other nodes in the data sharing system. This allows for the subsequent broadcasting of generated blocks to other nodes in the data sharing system based on their node identifiers. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 only uses IP addresses as an example.

[0112] Table 1

[0113]

[0114]

[0115] In one scenario, node 101 can be the initiator of the transaction (also referred to as the first node in this application). The first node can, based on a transaction instruction, instruct the transfer of the target digital asset from its transaction address to a second node (the recipient of the target digital asset), such as the transaction address of node 102; then, it can examine all UTXOs of the first node, select at least one UTXO from the remaining digital assets of the first node, and generate first transaction data based on at least one UTXO and the transfer instruction. The current transaction uses at least one UTXO as the transaction input of the target digital asset, and the total remaining target digital assets of the output UTXOs of the target digital asset are equal to 0 or greater than a target threshold to avoid the generation of dust transactions.

[0116] Furthermore, the first node uploads the state change of the target digital asset (the state change of the target digital asset is used to represent the transfer of the target digital asset from the transaction address of the first node to the transaction address of the second node) to the blockchain network.

[0117] In one implementation, each node in the data-sharing system 100 stores the same blockchain. The blockchain consists of multiple blocks; see [link to relevant documentation]. Figure 2 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 is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0118] Optionally, the blockchain can use the Unspent Transaction Output (UTX0) model to record various transaction data associated with the associated node devices. Here, an unspent transaction output refers to a transaction output in the blockchain that does not appear in the transaction inputs of other blocks.

[0119] When generating the individual blocks in the blockchain, see Figure 3 When a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

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

[0121] Wherein, 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 determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0122] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node where the blockchain resides sends the newly generated block to other nodes in its data sharing system based on the node identifiers of other nodes in the data sharing system. The other nodes then verify the newly generated block and add it to their stored blockchain after verification.

[0123] UTXO blockchain one-time encapsulation technology is considered an effective technique to improve the scalability of UTXO blockchains such as digital assets, and has recently been widely adopted. However, current UTXO blockchain one-time encapsulation technology incurs significant costs for both the receiver and the sender, resulting in high verification costs for the receiver and high storage costs for the sender.

[0124] Digital assets are a peer-to-peer distributed financial system that uses the UXTO model to support decentralized transfers by users without the intervention of third-party institutions. However, the UXTO model currently used by digital assets is essentially a Turing-complete script and cannot support state-based smart contracts, which limits the expansion of business scenarios on digital asset systems.

[0125] In related technologies, extended protocols for digital asset system functions employ UTXO one-time encapsulation technology, enabling digital assets to support smart contracts with runtime state models. However, this technology requires the recipient to fully accept and compute all prior transactions within the accepted UTXO one-time encapsulation, resulting in high verification costs for the recipient. Furthermore, the network and computational demands for verification increase over time, further escalating costs. For the sender of the UTXO one-time encapsulation, it needs to continuously hold and safeguard all prior transactions for its assets, incurring high storage costs. Current technologies result in significant cost inefficiencies for both the recipient and the sender.

[0126] To address the issues of high verification costs for receivers and high storage costs for senders in existing blockchain full nodes, this application proposes a blockchain-based data processing method that reduces costs for both receivers and senders through a third-party verification server.

[0127] The following describes a blockchain-based data processing method provided by an embodiment of this application, which can be executed by a data sharing system. Please refer to [link / reference]. Figure 4 The blockchain-based data processing method provided in this application includes steps S110 to S140. Specifically:

[0128] S110. Based on the transaction instruction, the target digital asset is transferred from the transaction address of the first node to the transaction address of the second node, and the status change information of the target digital asset is recorded in the blockchain.

[0129] Among them, the state change information of the target digital asset is used to represent the transfer of the target digital asset from the transaction address of the first node to the transaction address of the second node.

[0130] It is understood that the target digital asset can be an Unspent Output (UTXO). The first node can receive transaction information input by user 'a' from the client. This transaction information may include the target digital asset, the sender of the target digital asset (the transaction address of the first node), the receiver of the target digital asset (the transaction address of the second node), and additional transaction information. The additional transaction information may include the product or service that the target digital asset is being exchanged for. For example, when the transaction details indicate that the first node spends a specific target digital asset to exchange for a specific product, such as a mobile phone, from the second node, this transaction information can be represented as follows:

[0131] TX4<A,B,100> +SigA;

[0132] Among them, TX4<A,B,100> +SigA indicates a transaction in which the first node's transaction address A provides the signature SigA, transferring 100 units of digital assets (the target digital asset) from its own address A to the second node's transaction address B.

[0133] After the transaction is completed, the state of the target digital asset will change, specifically from the transaction address of the first node to the transaction address of the second node. This state change information will be recorded on the blockchain. For example, this state change information can be represented as: UTXO State <A,B> This indicates that the state of the target digital asset UTXO has changed from transaction address A of the first node to transaction address B of the second node.

[0134] S120. Generate a verification request for the status change of the target digital asset based on the identification information of the target digital asset.

[0135] The verification request for the change of the state of the target digital asset carries the identification information of the target digital asset.

[0136] Understandably, the first node sends the identification information of the target digital asset in the transaction to the second node. For example, the identification information of the target digital asset can be represented as:

[0137] UTXO i ·FLAG=UTXOi ·Txid+":"+UTXO i .Index;

[0138] Among them, UTXO i .FLAG is the identifier of the i-th UTXO initiated by the first node. i .Txid is the hash identifier (hash ID) of the on-chain transaction of the blockchain containing the i-th UTXO. i .Index represents the output position of this UTXO in the on-chain transaction. Generally speaking, a UTXO... i .Index is usually 0, but it can also be other values ​​depending on the one-time encapsulation protocol, meaning that multiple UTXO one-time encapsulations are in the same on-chain transaction.

[0139] When the second node receives the identification information of the target digital asset sent by the first node, it generates a verification request for the state change of the target digital asset based on the identification information, and then sends the verification request carrying the identification information of the target digital asset to a third-party verification server. For example, the verification request for the state change of the target digital asset can be represented as:

[0140] REQUEST = <UTXO i .FLAG>;

[0141] Here, REQUEST represents a verification request for a change in the state of the target digital asset, UTXO i • FLAG represents the identifier information of the target digital asset.

[0142] Since the second node can verify the target digital asset through a third-party verification server, the first node does not need to send all the pre-transaction information of the target digital asset, thus saving the transmission cost from the first node to the second node.

[0143] S130. Send a verification request for the change of the target digital asset's status to the verification server.

[0144] The verification server is used to obtain the transfer path of the target digital asset based on the identification information of the target digital asset, verify the state change of the target digital asset based on the transfer path, and generate the current state change verification result. The transfer path is used to represent the transaction information and state change information of the target digital asset in M ​​transactions, where M is an integer greater than or equal to 1.

[0145] Understandably, the second node sends a verification request for the state change of the target digital asset, carrying the identification information of the target digital asset, to a third-party verification server. This third-party verification server 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 communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0146] After receiving a verification request for a change in the status of a target digital asset, the third-party verification server obtains the transfer path of all prior transactions of the target digital asset based on the identification information of the target digital asset carried in the verification request, and verifies the current status change of the target digital asset based on the transfer path, generating a current status change verification result.

[0147] The transfer path of the target digital asset records the sender and sender of the target digital asset throughout all transactions. For example, this transfer path can be represented as:

[0148] Path =<X→Y→Z→A→B> ;

[0149] Wherein, X→Y→Z→A→B indicates that in the first transaction, the target digital asset is sent from the transaction address X of the third node to the transaction address Y of the fourth node; in the second transaction, it is sent from the transaction address Y of the fourth node to the transaction address Z of the fifth node; in the third transaction, it is sent from the transaction address Z of the fifth node to the transaction address A of the first node; and in the current transaction, it is sent from the transaction address A of the first node to the transaction address B of the second node.

[0150] The state change of the target digital asset is verified based on its transfer path, a current state change verification result is generated, and this result is sent to the second node. The current state change verification result includes either "current state change verification successful" or "current state change verification failed."

[0151] Specifically:

[0152] If the transfer path of the target digital asset indicates that the target digital asset has been transferred from the transaction address of the first node to the transaction address of the second node, and the status of the target digital asset indicates that the status of the target digital asset has changed from the transaction address of the first node to the transaction address of the second node, then it means that the status change of the target digital asset is successful, and the generated current status change verification result is that the current status change verification is successful.

[0153] If the transfer path of the target digital asset no longer indicates that the target digital asset has been transferred from the transaction address of the first node to the transaction address of the second node, for example, if the last node in the transfer path of the target digital asset is the first node, and the status of the target digital asset indicates that the status of the target digital asset has changed from the transaction address of the first node to the transaction address of the second node, then it means that the status change of the target digital asset has failed, and the generated current status change verification result is that the current status change verification has failed.

[0154] If the transfer path of the target digital asset indicates that the target digital asset has been transferred from the transaction address of the first node to the transaction address of the second node, but the status of the target digital asset does not indicate that the status of the target digital asset has changed from the transaction address of the first node to the transaction address of the second node, for example, if the status of the target digital asset still indicates that the target digital asset is the transaction address of the first node, then it means that the status change of the target digital asset has failed, and the generated current status change verification result is current status change verification failed.

[0155] S140. Receive the current state change verification result. If the current state change verification result indicates that the state change of the target digital asset is successful, verify the digital asset of the second node.

[0156] Understandably, the second node receives the current state change verification result. If the current state change verification result indicates that the target digital asset's state change was successful, then further verification of the second node's digital assets is required. Specifically, this involves verifying whether the second node's digital assets contain the target digital asset.

[0157] For easier understanding, please refer to Figure 5 , Figure 5This is a sequence diagram of a blockchain-based data processing method provided in this application embodiment. User A transfers a target digital asset from the transaction address of a first node to the transaction address of a second node through a client. Based on the transaction instruction, the target digital asset is transferred from the transaction address of the first node to the transaction address of the second node, and the state change of the target digital asset is recorded in the blockchain. The first node sends the identification information of the target digital asset to the second node. After receiving the identification information of the target digital asset, the second node generates a verification request for the state change of the target digital asset and sends the verification request to a third-party verification server. The third-party verification server stores all transaction information and all transfer paths of the target digital asset. The verification server reads the transfer path of the target digital asset, verifies the state change of the target digital asset according to the transfer path, generates a current state change verification result, and sends the current state change verification result to the second node. The second node receives the current state change verification result. If the current state change verification result indicates that the state change of the target digital asset is successful, the second node verifies its own digital assets to determine whether the target digital asset is included in all its digital assets.

[0158] Please see Figure 6 , Figure 6 This is a schematic diagram of a blockchain-based data processing method provided in an embodiment of this application. User A executes the current transaction through a client, transferring the target digital asset (100 units of UTXO) from the transaction address of the first node to the transaction address of the second node, TX4.<A,B,100> +SigA changes the state of the target digital asset from the transaction address of the first node to the transaction address of the second node, and records this state change on the blockchain. The first node sends the identification information of the target digital asset to the second node. After receiving the identification information, the second node generates a verification request for the state change of the target digital asset and sends the verification request to a third-party verification server. Upon receiving the verification request, the third-party verification server obtains the transfer path of all previous transactions of the target digital asset based on the identification information carried in the verification request, verifies the current state change of the target digital asset according to the transfer path, generates a current state change verification result, and sends the current state change verification result to the second node. The second node receives the current state change verification result. If the current state change verification result indicates that the state change of the target digital asset was successful, further verification of the digital asset by the second node is required.

[0159] The method provided in this application stores the transfer path of the preceding transactions of the target digital asset in a third-party verification server. During the receiving and verification stage of the target digital asset, the second node, as the recipient of the target digital asset, does not need to accept the transfer path of all preceding transactions of the target digital asset. Instead, it verifies the current state change of the target digital asset through the third-party verification server. The second node, as the recipient of the target digital asset, only needs to receive the state change result of the target digital asset, thereby reducing the receiving party's acceptance and verification costs for all preceding transactions of the target digital asset.

[0160] In this application Figure 4 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 7 The blockchain-based data processing method further includes steps S210 to S220. Specifically:

[0161] S210. Analyze the transfer path of the target digital asset to obtain M preceding transaction information and M preceding status change information of the target digital asset.

[0162] Understandably, after receiving a verification request for a change in the status of a target digital asset, the third-party verification server obtains the transfer path of all the preceding transactions of the target digital asset based on the identification information of the target digital asset carried in the verification request, parses the transfer path of the target digital asset, and obtains M preceding transaction information and M preceding status change information of the target digital asset.

[0163] Specifically, the prior transaction information can be represented as TXI<transferor's transaction address, recipient's transaction address, target digital asset>.

[0164] +Transaction address signature of the sender; Pre-existing state change information can be represented as State. i =EXEC(State i-1 ,TXi).

[0165] For example, this transfer path can be represented as:

[0166] Path =<X→Y→Z→A→B> ;

[0167] Wherein, X→Y→Z→A→B indicates that in the first transaction, the target digital asset is sent from the transaction address X of the third node to the transaction address Y of the fourth node; in the second transaction, it is sent from the transaction address Y of the fourth node to the transaction address Z of the fifth node; in the third transaction, it is sent from the transaction address Z of the fifth node to the transaction address A of the first node; and in the current transaction, it is sent from the transaction address A of the first node to the transaction address B of the second node.

[0168] Parsing the transfer path yielded four preceding transaction details and four preceding status change details. Specifically, the four preceding transaction details include:

[0169] TX1<X,Y,100> +SigX indicates a transaction where the transaction address X of the third node provides the signature SigX, and transfers 100 units of digital assets (the target digital assets) from its own address X to the transaction address Y of the fourth node.

[0170] TX2<Y,Z,100> +SigY indicates a transaction in which the transaction address Y of the fourth node provides the signature SigY, and transfers 100 units of digital assets (the target digital assets) from its own address Y to the transaction address Z of the fifth node.

[0171] TX3<Z,A,100> +SigZ indicates a transaction where the fifth node's transaction address Z provides the signature SigZ, transferring 100 units of digital assets (the target digital asset) from its own address Z to the first node's transaction address A.

[0172] TX4<A,B,100> +SigA indicates a transaction where the first node's transaction address A provides the signature SigA, transferring 100 units of digital assets (the target digital asset) from its own address A to the second node's transaction address B.

[0173] The four preceding status change messages include:

[0174] State1 = EXEC(State0,TX1) indicates that the state of the target digital asset has changed from the transaction address X of the third node to the transaction address Y of the fourth node;

[0175] State2 = EXEC(State1,TX2) indicates that the state of the target digital asset has changed from the transaction address Y of the fourth node to the transaction address Z of the fifth node;

[0176] State3 = EXEC(State2,TX3) indicates that the state of the target digital asset has changed from the transaction address Z of the fifth node to the transaction address A of the first node;

[0177] State4 = EXEC(State3,TX4) indicates that the state of the target digital asset has changed from transaction address A of the first node to transaction address B of the second node;

[0178] S220. Based on the M prior transaction information and M prior state change information of the target digital asset, verify the state change information of the target digital asset and generate the current state change verification result.

[0179] Understandably, based on M prior transaction information and M prior state change information of the target digital asset, the state change of the target digital asset is verified, and the current state change verification result is generated.

[0180] For preferred options, please refer to [link / reference]. Figure 8 Step S220 further includes sub-steps S221 to S222.

[0181] Specifically:

[0182] S221. If the M preceding state change information includes the state change information of the target digital asset, then the current state change verification result is successful.

[0183] S222. If the M preceding state change information does not include the state change information of the target digital asset, then the current state change verification result is verification failure.

[0184] For example, the state of the target digital asset is changed to UTXO. State <A,B> This indicates that the state of the target digital asset UTXO has changed from transaction address A of the first node to transaction address B of the second node. The preceding state change information, State4 = EXEC(State3,TX4), indicates that the state of the target digital asset has changed from transaction address A of the first node to transaction address B of the second node; therefore, the current state change verification result is successful. If the preceding state change information used to indicate the state change of the target digital asset is not included among the four preceding state change information, then the current state change verification result is unsuccessful.

[0185] The method provided in this application analyzes the transfer path of a target digital asset to obtain M preceding transaction information and M preceding state change information of the target digital asset, providing data support for subsequent verification. Based on the M preceding transaction information and M preceding state change information of the target digital asset, the state change of the target digital asset is verified, and a current state change verification result is generated, ensuring the accuracy and reliability of the state change of the target digital asset.

[0186] In this application Figure 7In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 9 Step S140 further includes sub-steps S141 to S142.

[0187] Specifically:

[0188] S141. Receive the most recent transaction information from the M preceding transaction information, and obtain the digital asset holding information of the second node.

[0189] Understandably, if the current state change verification result indicates that the target digital asset's state change was successful, the second node needs to verify whether its digital assets contain the target digital asset. The second node needs to request a third-party verification server to send the most recent of the M preceding transaction information, along with the digital asset holding information of the acquirer itself. Specifically, the second node generates a request instruction for the target preceding transaction information, which is the most recent of the M preceding transaction information. After receiving the request instruction for the target preceding transaction information, the third-party verification server, based on the transaction times of the M preceding transaction information, determines the most recent preceding transaction information from the M preceding transaction information and sends it to the second node.

[0190] The second node also needs to obtain digital asset holding information from the blockchain, which includes the value of the digital assets held.

[0191] S142. Verify the digital assets actually held by the second node based on the previous transaction information most recent to the current time and the digital asset holding information of the second node.

[0192] Understandably, the most recent preceding transaction information is the transaction closest to the current time among M preceding transactions. The second node's digital asset holding information, obtained from the blockchain, includes the quantity or value of digital assets currently held by the second node. Based on the most recent preceding transaction information, the quantity of digital assets received by the second node in that transaction can be determined. The calculated quantity of digital assets the second node should hold is compared with the actual quantity held by the second node. If they are equal, the second node's actual digital assets match the quantity calculated from the preceding transaction information, and the verification is successful. If they are not equal, a discrepancy exists, potentially indicating that the digital assets have been tampered with, lost, or due to other anomalies, and the verification fails. This ensures that the digital assets actually held by the second node are consistent with the transaction information recorded on the blockchain, thereby enhancing the security and credibility of digital asset transactions. Furthermore, this verification method can promptly identify potential problems and take corresponding measures to protect the security of digital assets.

[0193] The method provided in this application reduces the amount of data to be processed and improves verification efficiency by acquiring the most recent prior transaction information. Verification based on prior transaction information and the digital asset holding information of the second node ensures accuracy and avoids inaccurate verification results due to data errors or tampering. Verifying the digital assets actually held by the second node prevents illegal tampering or theft, enhancing system security. Since the most recent prior transaction information is used during verification, the real-time nature of the verification results is guaranteed, allowing for timely detection of changes in the state of digital assets. Only necessary prior transaction information and digital asset holding information are required, avoiding the transmission of large amounts of unnecessary data and reducing communication overhead. This verification method can be easily extended to scenarios involving large amounts of digital assets, exhibiting good scalability.

[0194] In this application Figure 9 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 10 Sub-step S142 further includes sub-steps S1421 to S1423. Specifically:

[0195] S1421. Generate the digital asset holding value of the second node based on the previous transaction information most recent to the current time and the digital asset holding information of the second node.

[0196] Understandably, the digital asset holdings of the second node are calculated or determined based on the most recent prior transaction information and the second node's digital asset holding information. This may involve accumulating the digital asset transfer quantities in the prior transaction information, or calculating the amount of digital assets the second node should hold at the current moment according to specific rules and algorithms.

[0197] S1422, If the digital asset holding value of the second node is equal to the digital asset value actually held by the second node, generate a message indicating that the digital asset actually held by the second node has been successfully verified.

[0198] Understandably, when the calculated digital asset holding value of the second node matches the actual digital asset holding value of the second node, the verification is considered successful, meaning that the actual digital assets held by the second node are consistent with the quantity calculated based on the preceding transaction information. In this case, a verification success message is generated, indicating that the digital asset holding situation of the second node is correct.

[0199] S1423. If the value of digital assets held by the second node is not equal to the value of digital assets actually held by the second node, generate a message indicating that the verification of digital assets actually held by the second node has failed.

[0200] Understandably, if the calculated digital asset holding value of the second node does not match the actual value of the digital assets held by the second node, it indicates a discrepancy, which may be due to the digital assets being tampered with, lost, or experiencing other anomalies. In this case, a verification failure message is generated, indicating that there is a problem with the digital asset holding status of the second node, requiring further investigation or appropriate measures.

[0201] For example, if the most recent previous transaction information is TX4<A,B,100> +SigA indicates a transaction where transaction address A of the first node provides a signature (SigA) to transfer 100 units of digital assets (the target digital asset) from its own address A to transaction address B of the second node. The second node's digital asset holding information is 260 units of digital assets. Adding the quantity of the target digital asset in the preceding transaction information to the quantity of digital assets in the second node's digital asset holding information yields a value of 360 units of digital assets held by the second node. The second node calculates the actual value of its held digital assets. If the calculated value of 360 units of digital assets equals the actual value of the digital assets held by the second node, a message indicating successful verification of the digital assets held by the second node is generated; otherwise, a message indicating verification failure of the digital assets held by the second node is generated.

[0202] The method provided in this application verifies the accuracy of the digital asset holding status of the second node by comparing the calculated digital asset holding value with the actual digital asset holding value. If the verification is successful, it indicates that the status change and holding status of the target digital asset are reliable; if the verification fails, further processing is required to ensure the security and accuracy of the target digital asset. This verification process helps improve the credibility and security of target digital asset transactions.

[0203] For easier understanding, please refer to Figure 11 , Figure 11 This is a schematic diagram of a blockchain-based data processing method provided in an embodiment of this application. User a is a user who does not use a third-party verification server. When the user receives a one-time UTXO encapsulation, they need to read all the previously uploaded one-time UTXO encapsulation transactions (from the first transaction to the i-th transaction) from their own private blockchain node or public blockchain node:

[0204] State i =EXEC(State i-1 ,TXi);

[0205] Where EXEC is the execution function in user a's local smart contract virtual machine or other asset execution environment. For user a, there is only one transaction, i.e., the judgment is:

[0206] State1 = EXEC(State0,TX1);

[0207] And verify whether its own target state is the value it expects, that is:

[0208] State i BalanceOf[A] == 100;

[0209] If the verification passes, user A believes that they have indeed received the corresponding assets.

[0210] The above verification follows the traditional one-time UTXO encapsulation. In future asset transfers, as the number of transfers increases, i gradually increases. During the continuous execution of the EXEC function, a large amount of user a's local computing resources will be consumed. At the same time, receiving TXI also requires a large amount of user a's network resources, resulting in high costs. This is also the pain point that this application needs to address.

[0211] If user A needs to send an asset transfer to user B, then the first node corresponding to user A initiates TX2 in the graph, encapsulates TX2 into UTXO2, spends the unspent output UTXO1, sends it to the second node corresponding to user B, and records it in the blockchain.

[0212] The first node corresponding to user a sends the identifier of the UTXO2 it initiated to the second node corresponding to user b, or the second node corresponding to user b requests the UTXO2 identifier from the first node corresponding to user a.

[0213] The identifier for UTXO2 can be represented as:

[0214] UTXO i .FLAG=UTXO i .Txid+":"+UTXO i .Index;

[0215] Among them, UTXO i .FLAG is the identifier of the i-th UTXO initiated by the first node corresponding to user a, Txid is the hash ID of the on-chain transaction of its blockchain, and Index is the output position of the UTXO in the on-chain transaction. Generally, Index is usually 0, but it can also be other values ​​depending on the one-time encapsulation protocol, that is, multiple UTXOs are encapsulated in the same on-chain transaction.

[0216] User B used a third-party verification cloud service for verification, so the first node corresponding to User A did not need to send the complete content or consume network resources.

[0217] User b's corresponding second node initiates a verification request for the state change of the target digital asset to a third-party verification cloud service, as follows:

[0218] REQUEST = <UTXO i .FLAG>;

[0219] Among them, the third-party verification cloud service can charge user B based on the size of the REQUEST network packets, the request frequency, the total number of requests, the number of subsequent verifications, the verification duration, etc. (either prepaid or postpaid).

[0220] Third-party verification cloud services verify data in the cloud based on UTXO. i .FLAG retrieves this UTXO i The process itself, and all the preceding UTXOs it consumes, is analyzed, and all preceding transaction information is parsed and executed in the cloud:

[0221] State i =CLOUD_EXEC(State i-1 ,TXi);

[0222] CLOUD_EXEC is a computation function performed in the smart contract virtual machine or other computing environment of a third-party verification cloud service.

[0223] Finally, if UTXO i If the state transition is successful, the third-party verification cloud service returns a verification pass to the second node; otherwise, it returns a verification failure.

[0224] For users who require strict status verification, third-party verification cloud services can return a specific status after the final execution. In this case, the request should be:

[0225] REQUEST = <UTXO i .FLAG,BalanceOf[B]>;

[0226] That is, the REQUEST includes the key of the state to be queried, which is BalanceOf[B].

[0227] Final return:

[0228] RESPONSE = State i .BalanceOf[B];

[0229] The second node can determine the legality of the one-time UTXO encapsulation transfer for user A based on the RESPONSE returned by the third-party verification cloud service.

[0230] Therefore, by using third-party verification cloud services, the computing and network resource requirements can be transferred to cloud vendors during the one-time packaging stage of UTXO verification at the receiving end. This allows cloud vendors to reduce the average verification cost per user by serving a large number of users.

[0231] In this application Figure 4 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 12 The blockchain-based data processing method also includes steps S310 to S330. Specifically:

[0232] S310. Generate a transfer path request for the target digital asset based on the identification information of the target digital asset.

[0233] The transfer path request for the target digital asset carries the identification information of the target digital asset.

[0234] Understandably, if user A uses a third-party verification server, before transferring the target digital asset from the transaction address of the first node to the transaction address of the second node, it needs to verify the digital assets in the transaction address of the first node to confirm that the target digital asset to be transferred is present in the digital assets in the transaction address of the first node. Therefore, the first node needs to generate a transfer path request for the target digital asset based on the identification information of the target digital asset to be transferred.

[0235] For example, a transfer path request for a target digital asset can be represented as:

[0236] EQUEST′= <UTXO N-1 .FLAG>;

[0237] Where EQUEST′ represents the transfer path request for the target digital asset, UTXO N-1 .FLAG indicates UTXO i All preceding transactions corresponding to .FLAG.

[0238] S320: Send the transfer path request for the target digital asset to the verification server.

[0239] The verification server is used to obtain the transfer path of the target digital asset based on the transfer path request of the target digital asset.

[0240] Understandably, the first node sends a transfer path request for the target digital asset to a third-party verification server. Upon receiving the transfer path request from the first node, the verification server retrieves the transfer path of the target digital asset based on the identification information carried in the request and then sends the transfer path back to the first node.

[0241] The transfer path of the target digital asset records the sender and sender of the target digital asset throughout all transactions. For example, this transfer path can be represented as:

[0242] Path =<X→Y→Z→A> ;

[0243] Wherein, X→Y→Z→A means that in the first transaction, the target digital asset is sent from the transaction address X of the third node to the transaction address Y of the fourth node; in the second transaction, it is sent from the transaction address Y of the fourth node to the transaction address Z of the fifth node; and in the third transaction, it is sent from the transaction address Z of the fifth node to the transaction address A of the first node.

[0244] The third-party verification server stores all prior transaction information of the target digital asset. This prior transaction information is then serialized to generate a transfer path for the target digital asset. Specifically, the third-party verification server obtains M prior transaction information entries for the target digital asset, where M is an integer greater than or equal to 1; it then serializes these M entries to generate the transfer path for the target digital asset.

[0245] For example, the prior transaction information of the target digital asset includes TX1<X,Y,100> +SigX, TX2<Y,Z,100> +SigY、TX3<Z,A,100> +SigZ. Specifically:

[0246] TX1<X,Y,100> +SigX indicates a transaction where the transaction address X of the third node provides the signature SigX, and transfers 100 units of digital assets (the target digital assets) from its own address X to the transaction address Y of the fourth node.

[0247] TX2<Y,Z,100> +SigY indicates a transaction in which the transaction address Y of the fourth node provides the signature SigY, and transfers 100 units of digital assets (the target digital assets) from its own address Y to the transaction address Z of the fifth node.

[0248] TX3<Z,A,100> +SigZ indicates a transaction where the fifth node's transaction address Z provides the signature SigZ, transferring 100 units of digital assets (the target digital asset) from its own address Z to the first node's transaction address A.

[0249] TX1, the pre-transaction information of the target digital asset<X,Y,100> +SigX, TX2<Y,Z,100> +SigY、TX3<Z,A,100> The +SigZ serialization process is used to obtain the transfer path Path of the target digital asset.<X→Y→Z→A> .

[0250] S330. Receive the transfer path of the target digital asset, verify the digital asset of the first node according to the transfer path of the target digital asset, and if the target digital asset is included in the digital asset of the first node, generate a transaction instruction based on the transaction address of the first node, the transaction address of the second node and the target digital asset.

[0251] Understandably, the first node receives the transfer path of the target digital asset and verifies the digital assets contained within it based on the transfer path to determine if the target digital asset is included. Once the first node verifies and confirms that its digital assets include the target digital asset, it generates a transaction instruction based on the first node's transaction address (the sending address of the target digital asset), the second node's transaction address (the receiving address of the target digital asset), and the target digital asset.

[0252] For easier understanding, please refer to Figure 13 , Figure 13 This application provides a timing diagram of a blockchain-based data processing method. Before transferring a target digital asset from the transaction address of a first node to the transaction address of a second node, user A needs to verify whether the first node's digital assets contain the target digital asset to be transferred. Since user A uses a third-party verification server, the third-party verification server stores the prior transaction information and transfer path information of the target digital asset. First, the first node generates a transfer path request for the target digital asset based on the identification information of the target digital asset and sends the transfer path request to the third-party verification server. Upon receiving the transfer path request, the third-party verification server obtains the transfer path of the target digital asset based on the identification information of the target digital asset carried in the transfer path request and sends the transfer path of the target digital asset to the first node. After receiving the transfer path of the target digital asset, the first node parses the transfer path to obtain the prior transaction information of the target digital asset. The first node verifies the target digital asset based on the prior transaction information. If the target digital asset is included in the first node's digital assets, the first node generates a transaction instruction based on the first node's transaction address (the sending address of the target digital asset), the second node's transaction address (the receiving address of the target digital asset), and the target digital asset.

[0253] The method provided in this application stores the prior transaction information and transfer path of the target digital asset in a third-party verification server. During the sending stage of the target digital asset, the first node, as the sender of the target digital asset, does not need to store the transfer path of all prior transactions of the target digital asset. Instead, the transfer path of the prior transactions of the target digital asset is stored in the third-party verification server. The transfer path of the target digital asset is obtained through the third-party verification server, which reduces the sending cost and storage cost of all prior transactions of the target digital asset for the sender.

[0254] In this application Figure 12 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 14 Step S330 further includes sub-steps S331 to S332. Specifically:

[0255] S331. Analyze the transfer path of the target digital asset to obtain M prior transaction information of the target digital asset.

[0256] Understandably, after the first node receives the transfer path of the target digital asset sent by the third-party verification server, it parses the transfer path of the target digital asset to obtain M pieces of prior transaction information of the target digital asset.

[0257] For example, the transfer path of the target digital asset is Path=<X→Y→Z→A> Analyzing the transfer path of the target digital asset yields three prior transaction details: X1<X,Y,100> +SigX, TX2<Y,Z,100> +SigY、TX3<Z,A,100> +SigZ. Specifically:

[0258] TX1<X,Y,100> +SigX indicates a transaction where the transaction address X of the third node provides the signature SigX, and transfers 100 units of digital assets (the target digital assets) from its own address X to the transaction address Y of the fourth node.

[0259] TX2<Y,Z,100> +SigY indicates a transaction in which the transaction address Y of the fourth node provides the signature SigY, and transfers 100 units of digital assets (the target digital assets) from its own address Y to the transaction address Z of the fifth node.

[0260] TX3<Z,A,100> +SigZ indicates a transaction where the fifth node's transaction address Z provides the signature SigZ, transferring 100 units of digital assets (the target digital asset) from its own address Z to the first node's transaction address A.

[0261] S332. Verify that the target digital asset is included in the digital assets of the first node based on the M prior transaction information of the target digital asset.

[0262] Understandably, the system verifies whether the first node's digital assets include the target digital asset based on the most recent of the M preceding transaction information for the target digital asset. If the receiving address of the most recent preceding transaction information is the transaction address of the first node, then the first node's digital assets include the target digital asset; otherwise, if the receiving address of the most recent preceding transaction information is not the transaction address of the first node, then the first node's digital assets do not include the target digital asset.

[0263] The method provided in this application embodiment involves a first node verifying whether the target digital asset is included in the digital asset by parsing the transfer path information of the target digital asset sent by a third-party verification server. This ensures the accuracy of the verification and avoids inaccurate verification results due to data errors or tampering.

[0264] In this application Figure 14 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 15 Sub-step S332 further includes sub-steps S3321 to S3322. Specifically:

[0265] S3321. If the most recent transaction among the M preceding transaction information of the target digital asset indicates that the receiving address of the target digital asset is the transaction address of the first node, then the digital assets of the first node include the target digital asset.

[0266] It is understandable that, from the M preceding transaction information of the target digital asset, the preceding transaction information closest to the current time is determined. If the receiving address of the target digital asset indicated in the preceding transaction information closest to the current time is the transaction address of the first node, it is proven that the target digital asset currently belongs to the transaction address of the first node, and it is determined that the target digital asset is included in the digital assets of the first node.

[0267] S3322. If the most recent transaction among the M preceding transaction information of the target digital asset indicates that the receiving address of the target digital asset is not the transaction address of the first node, then the target digital asset is not included in the digital assets of the first node.

[0268] It is understandable that, from the M preceding transaction information of the target digital asset, the preceding transaction information closest to the current time is determined. If the receiving address of the target digital asset indicated in the preceding transaction information closest to the current time is not the transaction address of the first node, it proves that the target digital asset does not currently belong to the transaction address of the first node, and thus it is determined that the target digital asset is not included in the digital assets of the first node.

[0269] The method provided in this application embodiment compares the receiving address of the target digital asset in the most recent preceding transaction of the target digital asset with the transaction address of the first node, thereby determining whether the target digital asset is a digital asset in the first node, which helps to improve the credibility and security of the target digital asset transaction.

[0270] For easier understanding, please refer to Figure 16 , Figure 16 This is a schematic diagram illustrating a blockchain-based data processing method provided in an embodiment of this application. User b uses a third-party verification server. Before the second node corresponding to user b needs to transfer the target digital asset to the third node corresponding to user x, the second node needs to verify whether its digital assets contain the target digital asset. Specifically, before the second node can transfer the target digital asset to the third node, it first needs to prove to the third node that it has neither stored nor received the required prior transaction for the target digital asset UTXO. Therefore, the second node initiates a transfer path request for the target digital asset to the third-party verification cloud service. The transfer path request for the target digital asset can be represented as: EQUEST′= <UTXO N-1 .FLAG>; where EQUEST' is the transfer path request for the target digital asset, UTXO N-1 .FLAG indicates UTXO i All preceding transactions corresponding to .FLAG. The third-party verification cloud service obtains the UTXO. i The preceding transaction information corresponding to .FLAG is queried sequentially to obtain the UTXO. i The first transaction information UTXO1 corresponding to .FLAG is the original UTXO used to create the related one-time encapsulated asset. The original UTXO can be represented as: UTXO i-1 =InputOf(UTXO) i ); where InputOf is the target UTXO of the query. i The function that outputs both spent and unspent data is recursively applied to obtain all preceding transactions: PRE_UTXOs = {UTXO1, UTXO2, ..., UTXO...} N-1If UTXO1 cannot be recursively queried within a limited time, a query error is returned to the user. Then, the preceding transaction information PRE_UTXOs is serialized to obtain the transfer path of the target digital asset. The third-party verification cloud service returns this information, RESPONSE′ = DUMPS(PRE_UTXOs), where RESPONSE′ is the corresponding return from the third-party verification cloud service to REQUEST′, and DUMPS is the serialization function. After the third-party verification cloud service successfully serializes and returns the information, it can charge user b based on the network packet size of RESPONSE′, the number of UTXOs, etc. (either prepaid or postpaid). After receiving the return from the third-party verification cloud service, the second node (the sender of the target digital asset) concatenates it with its own on-chain UTXOs to obtain: PROOF = {LOADS(PRE_UTXOs), UTXOs} N}, where LOADS is the deserialization function for the corresponding DUMPS, and finally we can obtain: PROOF={UTXO1,UTXO2,…,UTXO N Afterwards, the second node sends the PROOF to the third node. Upon receiving the PROOF, the third node independently and completely executes all state transitions in the PROOF to perform verification, referring to the verification process of traditional UTXO one-time encapsulation protocols (such as the RGB protocol).

[0271] In this application Figure 12 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation:

[0272] After sending the transfer path request for the target digital asset to the verification server, the process also includes:

[0273] Based on the verification request for the state change of the target digital asset, first billing information is generated, wherein the first billing information is used to characterize the cost statistics of the verification server for the verification request for the state change of the target digital asset of the second node.

[0274] Understandably, third-party verification servers can charge second-party nodes based on factors such as the size of network packets requested along the transfer path of the target digital asset, request frequency, total number of requests, number of subsequent verifications, and verification duration (either prepaid or postpaid).

[0275] After sending the transfer path request for the target digital asset to the verification server, it also includes:

[0276] Based on the transfer path request of the target digital asset, a second billing information is generated, wherein the second billing information is used to characterize the cost statistics of the transfer path request of the target digital asset of the first node by the verification server.

[0277] Understandably, once the third-party verification server successfully serializes and returns the data, it can similarly charge the first node based on factors such as the size of the network packets requested for the transfer path of the target digital asset, the number of UTXOs, etc. (either prepaid or postpaid).

[0278] The method provided in this application, by generating different billing information, ensures that the verification server receives reasonable compensation for its services, thus reflecting fairness. By calculating costs based on different factors, nodes are encouraged to utilize resources more rationally when using the verification server, avoiding unnecessary waste. With reasonable revenue guarantees, the verification server can better provide stable and reliable verification services.

[0279] For easier understanding, please refer to Figure 17 , Figure 17 This is an application environment diagram of the blockchain data processing method in the embodiments of this application, such as... Figure 17 As shown, the blockchain data processing method in this embodiment is applied to a blockchain data processing system. The blockchain data processing system includes a server and terminal devices. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0280] The server first receives a verification request for the state change of the target digital asset sent by the second node, wherein the verification request for the state change of the target digital asset carries the identification information of the target digital asset; then, the server obtains the transfer path of the target digital asset based on the identification information of the target digital asset; then, the server verifies the state change of the target digital asset based on the transfer path of the target digital asset and generates the current state change verification result; finally, the server sends the current state change verification result to the second node.

[0281] The following section will describe the blockchain-based data processing method in this application from the server's perspective. Please refer to [link / reference]. Figure 18 The blockchain-based data processing method provided in this application embodiment is executed by a verification server and includes steps S410 to S440. Specifically:

[0282] S410: Receive the verification request for the state change of the target digital asset sent by the second node.

[0283] The verification request for the state change of the target digital asset carries the identification information of the target digital asset.

[0284] Understandably, the second node sends a verification request for the state change of the target digital asset, carrying the identification information of the target digital asset, to a third-party verification server. The third-party verification server receives the verification request for the state change of the target digital asset sent by the second node.

[0285] S420. Obtain the transfer path of the target digital asset based on the identification information of the target digital asset.

[0286] Understandably, the third-party verification server parses the verification request for the state change of the target digital asset, obtains the identification information of the target digital asset, and obtains the transfer path of the target digital asset based on the identification information.

[0287] S430. Verify the state change of the target digital asset based on the transfer path of the target digital asset, and generate the current state change verification result.

[0288] Understandably, the third-party verification server obtains the transfer path of all previous transactions of the target digital asset based on the identification information of the target digital asset carried in the verification request for the state change of the target digital asset, and verifies the current state change of the target digital asset based on the transfer path, and generates the current state change verification result.

[0289] The transfer path of the target digital asset records the sender and sender of the target digital asset throughout all transactions. For example, this transfer path can be represented as:

[0290] Path =<X→Y→Z→A→B> ;

[0291] Wherein, X→Y→Z→A→B indicates that in the first transaction, the target digital asset is sent from the transaction address X of the third node to the transaction address Y of the fourth node; in the second transaction, it is sent from the transaction address Y of the fourth node to the transaction address Z of the fifth node; in the third transaction, it is sent from the transaction address Z of the fifth node to the transaction address A of the first node; and in the current transaction, it is sent from the transaction address A of the first node to the transaction address B of the second node.

[0292] The state change of the target digital asset is verified based on its transfer path, generating a current state change verification result. The current state change verification result includes "verification successful" and "verification failed." Specifically:

[0293] If the transfer path of the target digital asset indicates that the target digital asset has been transferred from the transaction address of the first node to the transaction address of the second node, and the status of the target digital asset indicates that the status of the target digital asset has changed from the transaction address of the first node to the transaction address of the second node, then it means that the status change of the target digital asset is successful, and the generated current status change verification result is that the current status change verification is successful.

[0294] If the transfer path of the target digital asset no longer indicates that the target digital asset has been transferred from the transaction address of the first node to the transaction address of the second node, for example, if the last node in the transfer path of the target digital asset is the first node, and the status of the target digital asset indicates that the status of the target digital asset has changed from the transaction address of the first node to the transaction address of the second node, then it means that the status change of the target digital asset has failed, and the generated current status change verification result is that the current status change verification has failed.

[0295] If the transfer path of the target digital asset indicates that the target digital asset has been transferred from the transaction address of the first node to the transaction address of the second node, but the status of the target digital asset does not indicate that the status of the target digital asset has changed from the transaction address of the first node to the transaction address of the second node, for example, if the status of the target digital asset still indicates that the target digital asset is the transaction address of the first node, then it means that the status change of the target digital asset has failed, and the generated current status change verification result is current status change verification failed.

[0296] Furthermore, the transfer path of the target digital asset is analyzed to obtain M preceding transaction information and M preceding state change information of the target digital asset, where M is an integer greater than or equal to 1; if the M preceding state change information includes preceding state change information used to indicate the state change of the target digital asset, the current state change verification result is successful; if the M preceding state change information does not include preceding state change information used to indicate the state change of the target digital asset, the current state change verification result is unsuccessful.

[0297] After receiving a verification request for a change in the status of a target digital asset, the third-party verification server obtains the transfer path of all the preceding transactions of the target digital asset based on the identification information of the target digital asset carried in the verification request. It then parses the transfer path of the target digital asset to obtain M preceding transaction information and M preceding status change information of the target digital asset.

[0298] Specifically, the prior transaction information can be represented as TXI<transferor's transaction address, recipient's transaction address, target digital asset>.

[0299] +Transaction address signature of the sender; Pre-existing state change information can be represented as State. i =EXEC(State i-1 ,TXi).

[0300] For example, this transfer path can be represented as:

[0301] Path =<X→Y→Z→A→B> ;

[0302] Wherein, X→Y→Z→A→B indicates that in the first transaction, the target digital asset is sent from the transaction address X of the third node to the transaction address Y of the fourth node; in the second transaction, it is sent from the transaction address Y of the fourth node to the transaction address Z of the fifth node; in the third transaction, it is sent from the transaction address Z of the fifth node to the transaction address A of the first node; and in the current transaction, it is sent from the transaction address A of the first node to the transaction address B of the second node.

[0303] Parsing the transfer path yielded four preceding transaction details and four preceding status change details. Specifically, the four preceding transaction details include:

[0304] TX1<X,Y,100> +SigX indicates a transaction where the transaction address X of the third node provides the signature SigX, and transfers 100 units of digital assets (the target digital assets) from its own address X to the transaction address Y of the fourth node.

[0305] TX2<Y,Z,100> +SigY indicates a transaction in which the transaction address Y of the fourth node provides the signature SigY, and transfers 100 units of digital assets (the target digital assets) from its own address Y to the transaction address Z of the fifth node.

[0306] TX3<Z,A,100> +SigZ indicates a transaction where the fifth node's transaction address Z provides the signature SigZ, transferring 100 units of digital assets (the target digital asset) from its own address Z to the first node's transaction address A.

[0307] TX4<A,B,100> +SigA indicates a transaction where the first node's transaction address A provides the signature SigA, transferring 100 units of digital assets (the target digital asset) from its own address A to the second node's transaction address B.

[0308] The four preceding status change messages include:

[0309] State1 = EXEC(State0,TX1) indicates that the state of the target digital asset has changed from the transaction address X of the third node to the transaction address Y of the fourth node;

[0310] State2 = EXEC(State1,TX2) indicates that the state of the target digital asset has changed from the transaction address Y of the fourth node to the transaction address Z of the fifth node;

[0311] State3 = EXEC(State2,TX3) indicates that the state of the target digital asset has changed from the transaction address Z of the fifth node to the transaction address A of the first node;

[0312] State4 = EXEC(State3,TX4) indicates that the state of the target digital asset has changed from transaction address A of the first node to transaction address B of the second node;

[0313] The target digital asset's status has been changed to UTXO State <A,B> This indicates that the state of the target digital asset UTXO has changed from transaction address A of the first node to transaction address B of the second node. The preceding state change information, State4 = EXEC(State3,TX4), indicates that the state of the target digital asset has changed from transaction address A of the first node to transaction address B of the second node; therefore, the current state change verification result is successful. If the preceding state change information used to indicate the state change of the target digital asset is not included among the four preceding state change information, then the current state change verification result is unsuccessful.

[0314] S440: Send the current state change verification result to the second node.

[0315] Understandably, the state change of the target digital asset is verified based on the transfer path of the target digital asset, a current state change verification result is generated, and the current state change verification result is sent to the second node.

[0316] The method provided in this application embodiment, in the target digital asset receiving and verification stage, does not require the second node, as the recipient of the target digital asset, to accept the transfer path of all the previous transactions of the target digital asset. Instead, it stores the transfer path of the previous transactions of the target digital asset in a third-party verification server and verifies the current state change of the target digital asset through the third-party verification server, thereby reducing the receiving party's acceptance cost and verification cost of all the previous transactions of the target digital asset.

[0317] In this application Figure 18 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 19 Following step S440 are steps S450 to S470. Specifically:

[0318] S450: Receive the verification request for the digital assets of the second node sent by the second node.

[0319] The verification request for the digital asset of the second node carries the identification information of the target digital asset and the identification information of the second node.

[0320] Understandably, in order to determine whether its digital assets include the target digital asset, the second node generates a verification request for the second node's digital asset based on the identification information of the target digital asset and the identification information of the second node, and sends the verification request for the second node's digital asset to a third-party verification server.

[0321] S460. Obtain the current status information of the target digital asset based on the identification information of the target digital asset, and obtain the digital asset holding information of the second node based on the identification information of the second node.

[0322] Understandably, the third-party verification server obtains the transfer path of the target digital asset based on its identification information, parses the transfer path to obtain M preceding state changes of the target digital asset, and determines the current state information most recent to the present time from these M preceding state changes. Additionally, it obtains the digital asset holding information of the second node based on the identification information of the second node.

[0323] S470: Send the current status information and the digital asset holding information of the second node to the second node.

[0324] Understandably, the third-party verification server sends the current state information of the target digital asset and the digital asset holding information of the second node to the second node, so that the second node can verify whether its own digital assets contain the target digital asset. Specifically:

[0325] Based on the most recent prior transaction information and the digital asset holding information of the second node, a digital asset holding value for the second node is generated; if the digital asset holding value of the second node is equal to the actual digital asset value held by the second node, a message indicating successful verification of the actual digital asset held by the second node is generated; if the digital asset holding value of the second node is not equal to the actual digital asset value held by the second node, a message indicating failed verification of the actual digital asset held by the second node is generated.

[0326] Understandably, based on the most recent prior transaction information and the second node's digital asset holding information, the digital asset holding value of the second node is calculated or determined. This may involve accumulating the digital asset transfer quantities in the prior transaction information, or calculating the amount of digital assets the second node should hold at the current moment according to specific rules and algorithms. When the calculated digital asset holding value of the second node matches the actual digital asset value held by the second node, the verification is successful, meaning the actual digital assets held by the second node are consistent with the quantity calculated based on the prior transaction information. In this case, a verification success message is generated, indicating that the second node's digital asset holding situation is correct. If the calculated digital asset holding value of the second node does not match the actual digital asset value held by the second node, a discrepancy exists, which may indicate that the digital assets have been tampered with, lost, or other abnormal circumstances. In this case, a verification failure message is generated, indicating that there is a problem with the second node's digital asset holding situation, requiring further investigation or appropriate measures.

[0327] For example, if the most recent previous transaction information is TX4<A,B,100> +SigA indicates a transaction where transaction address A of the first node provides a signature (SigA) to transfer 100 units of digital assets (the target digital asset) from its own address A to transaction address B of the second node. The second node's digital asset holding information is 260 units of digital assets. Adding the quantity of the target digital asset in the preceding transaction information to the quantity of digital assets in the second node's digital asset holding information yields a value of 360 units of digital assets held by the second node. The second node calculates the actual value of its held digital assets. If the calculated value of 360 units of digital assets equals the actual value of the digital assets held by the second node, a message indicating successful verification of the digital assets held by the second node is generated; otherwise, a message indicating verification failure of the digital assets held by the second node is generated.

[0328] The method provided in this application embodiment obtains the current status information of the target digital asset and the digital asset holding information of the second node through a verification server, ensuring that the second node's verification of its own digital assets is more accurate; it provides a reliable verification path for the second node, increases trust between nodes, and promotes the stable operation of the blockchain network; the second node does not need to perform a complex verification process itself, and can quickly and conveniently obtain verification results with the help of the verification server; centralized verification processing makes reasonable use of resources and improves verification efficiency.

[0329] In this application Figure 18 In one optional embodiment of the blockchain-based data processing method provided in the corresponding implementation, please refer to... Figure 20 Before step S410, steps S510 to S530 are also included. Specifically:

[0330] S510: Receive the transfer path request for the target digital asset sent by the first node.

[0331] The transfer path request for the target digital asset carries the identification information of the target digital asset.

[0332] S520. Request to obtain the transfer path of the target digital asset based on the transfer path of the target digital asset.

[0333] S530: Send the transfer path of the target digital asset to the first node.

[0334] Understandably, if user A uses a third-party verification server, before transferring the target digital asset from the transaction address of the first node to the transaction address of the second node, it needs to verify the digital assets in the transaction address of the first node to confirm that the target digital asset to be transferred is present in the digital assets in the transaction address of the first node. Therefore, the first node needs to generate a transfer path request for the target digital asset based on the identification information of the target digital asset to be transferred.

[0335] For example, a transfer path request for a target digital asset can be represented as:

[0336] EQUEST′= <UTXO N-1 ·FLAG>;

[0337] Where EQUEST′ represents the transfer path request for the target digital asset, UTXO N-1 ·FLAG indicates UTXO i All preceding transactions corresponding to .FLAG.

[0338] The first node sends a transfer path request for the target digital asset to a third-party verification server. Upon receiving the transfer path request from the first node, the verification server obtains the transfer path of the target digital asset based on the identification information of the target digital asset carried in the request, and then sends the transfer path of the target digital asset back to the first node.

[0339] The transfer path of the target digital asset records the sender and sender of the target digital asset throughout all transactions. For example, this transfer path can be represented as:

[0340] Path =<X→Y→Z→A> ;

[0341] Wherein, X→Y→Z→A means that in the first transaction, the target digital asset is sent from the transaction address X of the third node to the transaction address Y of the fourth node; in the second transaction, it is sent from the transaction address Y of the fourth node to the transaction address Z of the fifth node; and in the third transaction, it is sent from the transaction address Z of the fifth node to the transaction address A of the first node.

[0342] The third-party verification server stores all prior transaction information of the target digital asset. This prior transaction information is then serialized to generate a transfer path for the target digital asset. Specifically, the third-party verification server obtains M prior transaction information entries for the target digital asset, where M is an integer greater than or equal to 1; it then serializes these M entries to generate the transfer path for the target digital asset.

[0343] For example, the prior transaction information of the target digital asset includes TX1<X,Y,100> +SigX, TX2<Y,Z,100> +SigY、TX3<Z,A,100> +SigZ. Specifically:

[0344] TX1<X,Y,100> +SigX indicates a transaction where the transaction address X of the third node provides the signature SigX, and transfers 100 units of digital assets (the target digital assets) from its own address X to the transaction address Y of the fourth node.

[0345] TX2<Y,Z,100> +SigY indicates a transaction in which the transaction address Y of the fourth node provides the signature SigY, and transfers 100 units of digital assets (the target digital assets) from its own address Y to the transaction address Z of the fifth node.

[0346] TX3<Z,A,100> +SigZ indicates a transaction where the fifth node's transaction address Z provides the signature SigZ, transferring 100 units of digital assets (the target digital asset) from its own address Z to the first node's transaction address A.

[0347] TX1, the pre-transaction information of the target digital asset<X,Y,100> +SigX, TX2<Y,Z,100> +SigY、TX3<Z,A,100> The +SigZ serialization process is used to obtain the transfer path Path of the target digital asset.<X→Y→Z→A> .

[0348] The first node receives the transfer path of the target digital asset and verifies the digital assets contained within it based on the transfer path to determine if the target digital asset is included. Once the first node verifies and confirms that its digital assets include the target digital asset, it generates a transaction instruction based on the first node's transaction address (the sending address of the target digital asset), the second node's transaction address (the receiving address of the target digital asset), and the target digital asset itself.

[0349] The method provided in this application stores the prior transaction information and transfer path of the target digital asset in a third-party verification server. During the sending stage of the target digital asset, the first node, as the sender of the target digital asset, does not need to store the transfer path of all prior transactions of the target digital asset. Instead, the transfer path of the prior transactions of the target digital asset is stored in the third-party verification server. The transfer path of the target digital asset is obtained through the third-party verification server, which reduces the sending cost and storage cost of all prior transactions of the target digital asset for the sender.

[0350] The blockchain-based data processing device in this application is described in detail below. Please refer to [link / reference]. Figure 21 . Figure 21 This is a schematic diagram of an embodiment of the blockchain-based data processing device 10 in this application. The blockchain-based data processing device 10 includes: a current transaction information module 110, a state change verification request module 120, a verification request sending module 130, and a digital asset verification module 140; specifically:

[0351] The current transaction information module 110 is used to transfer the target digital asset from the transaction address of the first node to the transaction address of the second node based on the transaction instruction, and to record the state change of the target digital asset in the blockchain. The state change of the target digital asset is used to represent the transfer of the target digital asset from the transaction address of the first node to the transaction address of the second node.

[0352] The state change verification request module 120 is used to generate a state change verification request for the target digital asset based on the identification information of the target digital asset, wherein the state change verification request for the target digital asset carries the identification information of the target digital asset.

[0353] The verification request sending module 130 is used to send a verification request for the status change of the target digital asset to the verification server. The verification server is used to obtain the transfer path of the target digital asset based on the identification information of the target digital asset, verify the status change of the target digital asset based on the transfer path of the target digital asset, and generate the current status change verification result.

[0354] The digital asset verification module 140 is used to receive the current state change verification result and verify the digital asset of the second node when the current state change verification result indicates that the state change of the target digital asset is successful.

[0355] The apparatus provided in this application embodiment, during the target digital asset reception and verification stage, does not require the second node, as the recipient of the target digital asset, to accept the transfer path of all prior transactions of the target digital asset. Instead, it stores the transfer path of the prior transactions of the target digital asset in a third-party verification server and verifies the current state change of the target digital asset through the third-party verification server, thereby reducing the reception cost and verification cost of all prior transactions of the target digital asset.

[0356] In this application Figure 21 In an optional embodiment of the blockchain-based data processing apparatus provided in the corresponding embodiments, the verification server is further used for:

[0357] The transfer path of the target digital asset is analyzed to obtain M preceding transaction information and M preceding state change information of the target digital asset, where M is an integer greater than or equal to 1;

[0358] Based on M prior transaction information and M prior state change information of the target digital asset, the state change of the target digital asset is verified, and the current state change verification result is generated.

[0359] Furthermore, the verification server is also used for:

[0360] If the M preceding state change messages include preceding state change messages that indicate the state change of the target digital asset, then the current state change verification result is successful.

[0361] If none of the M preceding state change messages contain preceding state change messages used to indicate a state change of the target digital asset, then the current state change verification result is verification failure.

[0362] The apparatus provided in this application analyzes the transfer path of a target digital asset to obtain M preceding transaction information and M preceding state change information of the target digital asset, providing data support for subsequent verification. Based on the M preceding transaction information and M preceding state change information of the target digital asset, the state change of the target digital asset is verified, and a current state change verification result is generated, ensuring the accuracy and reliability of the state change of the target digital asset.

[0363] In this application Figure 21 In an optional embodiment of the blockchain-based data processing apparatus provided in the corresponding embodiment, the digital asset verification module 140 is further configured to:

[0364] Receive the most recent transaction information from among M previous transaction information, and obtain the digital asset holding information of the second node;

[0365] The digital assets actually held by the second node are verified based on the most recent previous transaction information and the digital asset holding information of the second node.

[0366] The apparatus provided in this application reduces the amount of data to be processed and improves verification efficiency by acquiring the most recent prior transaction information. Verification based on prior transaction information and the digital asset holding information of the second node ensures accuracy and avoids inaccurate verification results due to data errors or tampering. Verifying the digital assets actually held by the second node prevents illegal tampering or theft, enhancing system security. Since the most recent prior transaction information is used during verification, the real-time nature of the verification results is guaranteed, allowing for timely detection of changes in the state of digital assets. Only necessary prior transaction information and digital asset holding information are required, avoiding the transmission of large amounts of unnecessary data and reducing communication overhead. This verification method can be easily extended to scenarios involving large amounts of digital assets, exhibiting good scalability.

[0367] In this application Figure 21 In an optional embodiment of the blockchain-based data processing apparatus provided in the corresponding embodiment, the digital asset verification module 140 is further configured to:

[0368] Based on the most recent previous transaction information and the digital asset holding information of the second node, generate the digital asset holding value of the second node;

[0369] If the digital asset holding value of the second node is equal to the actual digital asset holding value of the second node, a message indicating successful verification of the actual digital asset holding of the second node is generated.

[0370] If the digital asset holding value of the second node is not equal to the actual digital asset value held by the second node, a message indicating that the verification of the actual digital asset held by the second node has failed will be generated.

[0371] The apparatus provided in this application verifies the accuracy of a second node's digital asset holding status by comparing the calculated digital asset holding value with the actual digital asset holding value. If the verification is successful, it indicates that the state change and holding status of the target digital asset are reliable; if the verification fails, further processing is required to ensure the security and accuracy of the target digital asset. This verification process helps improve the credibility and security of target digital asset transactions.

[0372] In this application Figure 21 In an optional embodiment of the blockchain-based data processing device provided in the corresponding embodiment, the current transaction information module 110 is further used for:

[0373] Based on the identification information of the target digital asset, a transfer path request for the target digital asset is generated, wherein the transfer path request for the target digital asset carries the identification information of the target digital asset.

[0374] The transfer path request of the target digital asset is sent to the verification server, whereby the verification server is used to obtain the transfer path of the target digital asset based on the transfer path request.

[0375] Receive the transfer path of the target digital asset, verify the digital asset of the first node according to the transfer path of the target digital asset, and if the target digital asset is included in the digital asset of the first node, generate a transaction instruction based on the transaction address of the first node, the transaction address of the second node and the target digital asset.

[0376] The apparatus provided in this application stores the prior transaction information and transfer path of the target digital asset in a third-party verification server. During the sending stage of the target digital asset, the first node, as the sender of the target digital asset, does not need to store the transfer path of all prior transactions of the target digital asset. Instead, it stores the transfer path of the prior transactions of the target digital asset in the third-party verification server and obtains the transfer path of the target digital asset through the third-party verification server, thereby reducing the sending cost and storage cost of all prior transactions of the target digital asset for the sender.

[0377] In this application Figure 21 In an optional embodiment of the blockchain-based data processing device provided in the corresponding embodiment, the current transaction information module 110 is further used for:

[0378] The transfer path of the target digital asset is analyzed to obtain M prior transaction information of the target digital asset;

[0379] The first node verifies the inclusion of the target digital asset in the target digital asset based on M prior transaction information of the target digital asset.

[0380] The apparatus provided in this application embodiment uses the prior transaction information obtained by parsing the transfer path of the target digital asset sent by the first node through a third-party verification server to verify whether the target digital asset is included in its digital assets. This ensures the accuracy of the verification and avoids inaccurate verification results due to data errors or tampering.

[0381] In this application Figure 21In an optional embodiment of the blockchain-based data processing device provided in the corresponding embodiment, the current transaction information module 110 is further used for:

[0382] If the most recent transaction among the M preceding transaction records of the target digital asset indicates that the receiving address of the target digital asset is the transaction address of the first node, then the digital assets of the first node include the target digital asset.

[0383] If the most recent transaction among the M preceding transaction records of the target digital asset indicates that the receiving address of the target digital asset is not the transaction address of the first node, then the target digital asset is not included in the digital assets of the first node.

[0384] The apparatus provided in this application embodiment can determine whether the target digital asset is a digital asset in the first node by comparing the receiving address of the target digital asset in the previous transaction that is closest to the current time with the transaction address of the first node, thereby helping to improve the credibility and security of the target digital asset transaction.

[0385] In this application Figure 21 In one optional embodiment of the blockchain-based data processing device provided in the corresponding embodiment, the blockchain-based data processing device further includes a billing module; specifically, the billing module is used for:

[0386] Based on the verification request for the state change of the target digital asset, first billing information is generated, wherein the first billing information is used to characterize the cost statistics of the verification server for the verification request for the state change of the target digital asset of the second node.

[0387] Based on the transfer path request of the target digital asset, a second billing information is generated, wherein the second billing information is used to characterize the cost statistics of the transfer path request of the target digital asset of the first node by the verification server.

[0388] The apparatus provided in this application ensures fairness by generating different billing information to guarantee reasonable compensation for the verification server's services. By calculating costs based on various factors, nodes are encouraged to utilize resources more efficiently when using the verification server, avoiding unnecessary waste. With reasonable revenue guarantees, the verification server can better provide stable and reliable verification services.

[0389] The blockchain-based data processing device in this application is described in detail below. Please refer to [link / reference]. Figure 22 . Figure 22This is a schematic diagram of an embodiment of the blockchain-based data processing device 20 in this application. The blockchain-based data processing device 20 includes: a state change verification request receiving module 210, a transfer path acquisition module 220, a state change verification module 230, and a state change verification result sending module 240; specifically:

[0390] The state change verification request receiving module 210 is used to receive the state change verification request of the target digital asset sent by the second node, wherein the state change verification request of the target digital asset carries the identification information of the target digital asset.

[0391] The transfer path acquisition module 220 is used to acquire the transfer path of the target digital asset based on the identification information of the target digital asset.

[0392] The state change verification module 230 is used to verify the state change of the target digital asset according to the transfer path of the target digital asset and generate the current state change verification result.

[0393] The status change verification result sending module 240 is used to send the current status change verification result to the second node.

[0394] The apparatus provided in this application embodiment, during the target digital asset reception and verification stage, does not require the second node, as the recipient of the target digital asset, to accept the transfer path of all prior transactions of the target digital asset. Instead, it stores the transfer path of the prior transactions of the target digital asset in a third-party verification server and verifies the current state change of the target digital asset through the third-party verification server, thereby reducing the reception cost and verification cost of all prior transactions of the target digital asset.

[0395] In this application Figure 22 In one optional embodiment of the blockchain-based data processing apparatus provided in the corresponding embodiments, the blockchain-based data processing apparatus further includes:

[0396] The target digital asset verification request receiving module is also used to receive the verification request of the second node's digital asset sent by the second node, wherein the verification request of the second node's digital asset carries the identification information of the target digital asset and the identification information of the second node.

[0397] The target digital asset information acquisition module is used to obtain the current status information of the target digital asset based on the identification information of the target digital asset, and to obtain the digital asset holding information of the second node based on the identification information of the second node.

[0398] The target digital asset information sending module is used to send the current status information and the digital asset holding information of the second node to the second node.

[0399] The apparatus provided in this application obtains the current status information of the target digital asset and the digital asset holding information of the second node through a verification server, ensuring that the second node's verification of its own digital assets is more accurate; it provides a reliable verification method for the second node, increases trust between nodes, and promotes the stable operation of the blockchain network; the second node does not need to perform a complex verification process itself, and can quickly and conveniently obtain verification results with the help of the verification server; centralized verification processing makes reasonable use of resources and improves verification efficiency.

[0400] In this application Figure 22 In one optional embodiment of the blockchain-based data processing apparatus provided in the corresponding embodiments, the blockchain-based data processing apparatus further includes:

[0401] The transfer path request receiving module is used to receive the transfer path request of the target digital asset sent by the first node, wherein the transfer path request of the target digital asset carries the identification information of the target digital asset.

[0402] The transfer path acquisition module is also used to acquire the transfer path of the target digital asset based on the transfer path request of the target digital asset;

[0403] The transfer path sending module is used to send the transfer path of the target digital asset to the first node.

[0404] The apparatus provided in this application stores the prior transaction information and transfer path of the target digital asset in a third-party verification server. During the sending stage of the target digital asset, the first node, as the sender of the target digital asset, does not need to store the transfer path of all prior transactions of the target digital asset. Instead, it stores the transfer path of the prior transactions of the target digital asset in the third-party verification server and obtains the transfer path of the target digital asset through the third-party verification server, thereby reducing the sending cost and storage cost of all prior transactions of the target digital asset for the sender.

[0405] Figure 23This is a schematic diagram of a server structure provided in an embodiment of this application. The server 300 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 322 (e.g., one or more processors) and memory 332, and one or more storage media 330 (e.g., one or more mass storage devices) for storing application programs 342 or data 344. The memory 332 and storage media 330 can be temporary or persistent storage. The program stored in the storage media 330 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the server. Furthermore, the CPU 322 may be configured to communicate with the storage media 330 and execute the series of instruction operations stored in the storage media 330 on the server 300.

[0406] Server 300 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0407] The steps performed by the server in the above embodiments can be based on this Figure 23 The server structure shown.

[0408] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0409] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0410] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0411] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0412] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0413] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A data processing method based on blockchain, characterized in that, include: Based on the transaction instruction, the target digital asset is transferred from the transaction address of the first node to the transaction address of the second node, and the status change information of the target digital asset is recorded in the blockchain. The status change information of the target digital asset is used to represent the transfer of the target digital asset from the transaction address of the first node to the transaction address of the second node. A verification request for a change in the status of a target digital asset is generated based on the identification information of the target digital asset, wherein the verification request for a change in the status of the target digital asset carries the identification information of the target digital asset. The verification request for the change of the target digital asset's status is sent to the verification server. The verification server is used to obtain the transfer path of the target digital asset based on the identification information of the target digital asset, verify the status change information of the target digital asset based on the transfer path of the target digital asset, and generate the current status change verification result. The transfer path is used to characterize the transaction information and status change information of the target digital asset in M ​​transactions, where M is an integer greater than or equal to 1. Upon receiving the current state change verification result, if the current state change verification result indicates that the state change of the target digital asset was successful, the digital asset of the second node is verified.

2. The data processing method based on blockchain as described in claim 1, characterized in that, The step of verifying the state change information of the target digital asset based on its transfer path and generating a current state change verification result includes: The transfer path of the target digital asset is analyzed to obtain M preceding transaction information and M preceding status change information of the target digital asset; Based on M prior transaction information and M prior state change information of the target digital asset, the state change information of the target digital asset is verified, and the current state change verification result is generated.

3. The data processing method based on blockchain as described in claim 2, characterized in that, The step of verifying the state change information of the target digital asset based on M prior transaction information and M prior state change information, and generating a current state change verification result, includes: If the M preceding state change information includes the state change information of the target digital asset, then the current state change verification result is successful. If the M preceding state change information does not include the state change information of the target digital asset, then the current state change verification result is verification failure.

4. The data processing method based on blockchain as described in claim 2, characterized in that, The verification of the digital assets of the second node includes: Receive the most recent transaction information from among M previous transaction information, and obtain the digital asset holding information of the second node; Based on the most recent prior transaction information and the digital asset holding information of the second node, the actual digital assets held by the second node are verified.

5. The data processing method based on blockchain as described in claim 4, characterized in that, The step of verifying the digital assets actually held by the second node based on the most recent prior transaction information and the digital asset holding information of the second node includes: Based on the most recent previous transaction information and the digital asset holding information of the second node, generate the digital asset holding value of the second node; If the digital asset holding value of the second node is equal to the actual digital asset holding value of the second node, a message indicating successful verification of the actual digital asset holding of the second node is generated. If the digital asset holding value of the second node is not equal to the actual digital asset value held by the second node, a message indicating that the verification of the actual digital asset held by the second node has failed is generated.

6. The data processing method based on blockchain as described in claim 1, characterized in that, The verification of the digital assets of the second node includes: A verification request for the digital asset of the second node is generated based on the identification information of the target digital asset and the identification information of the second node, wherein the verification request for the digital asset of the second node carries the identification information of the target digital asset and the identification information of the second node. The verification request for the digital asset of the second node is sent to the verification server, wherein the verification server is used to obtain the current status information of the target digital asset based on the identification information of the target digital asset, and to obtain the digital asset holding information of the second node based on the identification information of the second node. Receive the current status information and the digital asset holding information of the second node; Based on the current status information and the digital asset holding information of the second node, the actual digital assets held by the second node are verified.

7. The data processing method based on blockchain as described in claim 1, characterized in that, Before transferring the target digital asset from the transaction address of the first node to the transaction address of the second node based on the transaction instruction, the process also includes: Based on the identification information of the target digital asset, a transfer path request for the target digital asset is generated, wherein the transfer path request for the target digital asset carries the identification information of the target digital asset; The transfer path request of the target digital asset is sent to the verification server, wherein the verification server is used to obtain the transfer path of the target digital asset according to the transfer path request of the target digital asset; The system receives the transfer path of the target digital asset, verifies the digital asset of the first node based on the transfer path of the target digital asset, and generates the transaction instruction based on the transaction address of the first node, the transaction address of the second node, and the target digital asset if the target digital asset is included in the digital assets of the first node.

8. The data processing method based on blockchain as described in claim 7, characterized in that, The step of requesting to obtain the transfer path of the target digital asset based on the transfer path of the target digital asset includes: Obtain M prior transaction information of the target digital asset, where M is an integer greater than or equal to 1; The M preceding transaction information are serialized to generate the transfer path of the target digital asset.

9. The data processing method based on blockchain as described in claim 8, characterized in that, The step of verifying the digital asset of the first node based on the transfer path of the target digital asset includes: The transfer path of the target digital asset is analyzed to obtain M preceding transaction information of the target digital asset; The first node verifies that the target digital asset is included in the digital assets based on M prior transaction information of the target digital asset.

10. The blockchain-based data processing method as described in claim 9, characterized in that, The step of verifying that the target digital asset is included in the digital assets of the first node based on M prior transaction information of the target digital asset includes: If the most recent transaction among the M preceding transaction records of the target digital asset indicates that the receiving address of the target digital asset is the transaction address of the first node, then the digital assets of the first node include the target digital asset. If the most recent transaction among the M preceding transaction records of the target digital asset indicates that the receiving address of the target digital asset is not the transaction address of the first node, then the target digital asset is not included in the digital assets of the first node.

11. The data processing method based on blockchain as described in claim 7, characterized in that, After sending the verification request for the state change of the target digital asset to the verification server, the method further includes: Based on the verification request for the state change of the target digital asset, first billing information is generated, wherein the first billing information is used to characterize the cost statistics of the verification server for the verification request for the state change of the target digital asset of the second node; After sending the transfer path request for the target digital asset to the verification server, the method further includes: Based on the transfer path request of the target digital asset, second billing information is generated, wherein the second billing information is used to characterize the cost statistics of the transfer path request of the target digital asset of the first node performed by the verification server.

12. The blockchain-based data processing method as described in any one of claims 1-11, characterized in that, The verification server is used to perform: Receive a verification request for a state change of a target digital asset sent by a second node, wherein the verification request for a state change of the target digital asset carries the identification information of the target digital asset; The transfer path of the target digital asset is obtained based on the identification information of the target digital asset; The state change of the target digital asset is verified based on the transfer path of the target digital asset, and a current state change verification result is generated. The current state change verification result is sent to the second node.

13. The blockchain-based data processing method as described in claim 12, characterized in that, The verification server is also used to perform: Receive a verification request for the digital asset of the second node sent by the second node, wherein the verification request for the digital asset of the second node carries the identification information of the target digital asset and the identification information of the second node; The current status information of the target digital asset is obtained based on the identification information of the target digital asset, and the digital asset holding information of the second node is obtained based on the identification information of the second node. The current status information and the digital asset holding information of the second node are sent to the second node.

14. The blockchain-based data processing method as described in claim 12, characterized in that, The verification server is also used to perform: Receive a transfer path request for a target digital asset sent by the first node, wherein the transfer path request for the target digital asset carries the identification information of the target digital asset; Request to obtain the transfer path of the target digital asset based on the transfer path of the target digital asset; The transfer path of the target digital asset is sent to the first node.

15. A data processing device based on blockchain, characterized in that, include: The current transaction information module is used to transfer the target digital asset from the transaction address of the first node to the transaction address of the second node based on the transaction instruction, and record the state change of the target digital asset in the blockchain. The state change of the target digital asset is used to represent the transfer of the target digital asset from the transaction address of the first node to the transaction address of the second node. The status change verification request module is used to generate a verification request for a status change of the target digital asset based on the identification information of the target digital asset, wherein the status change verification request of the target digital asset carries the identification information of the target digital asset; The verification request sending module is used to send a verification request for the state change of the target digital asset to the verification server. The verification server is used to obtain the transfer path of the target digital asset based on the identification information of the target digital asset, verify the state change of the target digital asset based on the transfer path of the target digital asset, and generate a current state change verification result. The transfer path is used to characterize the transaction information and state change information of the target digital asset in M ​​transactions, where M is an integer greater than or equal to 1. The target digital asset verification module is used to receive the current state change verification result, and verify the digital asset of the second node when the current state change verification result indicates that the state change of the target digital asset is successful.

16. The blockchain-based data processing device as described in claim 15, characterized in that, The device further includes: The state change verification request receiving module is used to receive a verification request for a state change of a target digital asset sent by the second node, wherein the verification request for the state change of the target digital asset carries the identification information of the target digital asset. The transfer path acquisition module is used to acquire the transfer path of the target digital asset based on the identification information of the target digital asset. The status change verification module is used to verify the status change of the target digital asset according to the transfer path of the target digital asset and generate the current status change verification result. The status change verification result sending module is used to send the current status change verification result to the second node.

17. A computer device, characterized in that, include: Memory, processor, and bus system; The memory is used to store programs; The processor is used to execute programs in the memory, including executing the blockchain-based data processing method as described in any one of claims 1 to 14; The bus system is used to connect the memory and the processor to enable communication between the memory and the processor.

18. A computer-readable storage medium comprising instructions, characterized in that, When it is run on a computer, it causes the computer to perform the blockchain-based data processing method as described in any one of claims 1 to 14.

19. A computer program product, comprising a computer program, characterized in that, The computer program is executed by a processor using the blockchain-based data processing method as described in any one of claims 1 to 14.

Images