Blockchain-based data processing method and related device

Abstract

Embodiments of the present disclosure provide a data processing method based on a blockchain and related equipment. The method comprises: obtaining a first transaction request sent by a terminal device of a first request party, the first transaction request carrying a first business party identifier, first request party information and a first incoming parameter for executing the first transaction request; calling an intelligent contract to generate a first parameter passing hash value of the first incoming parameter; calling the intelligent contract to match the first business party identifier, the first request party information and the first parameter passing hash value with a transaction execution table; returning a target transaction execution result and a target transaction hash value matched with the first business party identifier, the first request party information and the first parameter passing hash value in the transaction execution table to the terminal device of the first request party, the target transaction hash value being different from a first transaction hash value of the first transaction request. The scheme provided by the embodiments of the present disclosure can guarantee the idempotency of transaction requests in the blockchain.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and more specifically, to a blockchain-based data processing method, node device, terminal device, electronic device, and computer-readable medium. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a distributed node system, nodes compete for the right to process data and become block-generating nodes. The generated blocks are then verified and confirmed by other nodes before being stored. This operating mechanism makes the data recorded in blocks within a blockchain virtually impossible to tamper with.

[0003] In business scenarios, businesses often require idempotency. For example, in a payment scenario, a user purchases goods and pays successfully, but a network error occurs when the result is returned, leading the user to believe the payment was unsuccessful. If the user submits a payment request again, a second payment may be deducted for the same order.

[0004] In real-world scenarios, due to blockchain response delays, business users may submit multiple transaction requests for the same business function. Inconsistent timestamps and other factors can lead to different hash values ​​for each transaction, even though the business parameters are identical. The blockchain may then identify these as multiple distinct business requests, resulting in an idempotency issue. Idempotency refers to the property that in a distributed environment, one or more requests from a user for the same operation yield consistent results, without any side effects from multiple clicks.

[0005] Therefore, there is a need for a new blockchain-based data processing method, node device, terminal device, electronic device, and computer-readable medium. Summary of the Invention

[0006] This disclosure provides a data processing method, apparatus, electronic device, and computer-readable medium based on blockchain, thereby at least partially solving the idempotency problem existing in blockchain in related technologies.

[0007] This disclosure proposes a blockchain-based data processing method. The method is applied to node devices in a blockchain network, where smart contracts are deployed to maintain a transaction execution table. The method includes: obtaining a first transaction request sent by a terminal device of a first requester, the first transaction request carrying a first business party identifier, first requester information, and a first input parameter for executing the first transaction request; invoking the smart contract to generate a first parameter hash value for the first input parameter; invoking the smart contract to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table; and returning the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester, wherein the target transaction hash value is different from the first transaction hash value of the first transaction request.

[0008] This disclosure proposes a blockchain-based data processing method. The method is applied to a terminal device communicating with a blockchain network, where smart contracts are deployed to maintain a transaction execution table. The method includes: generating a first transaction request via a first requester's terminal device, the first transaction request carrying a first business party identifier, first requester information, and a first input parameter for executing the first transaction request; generating a first transaction hash value for the first transaction request via the first requester's terminal device; sending the first transaction request to a node device in the blockchain network via the first requester's terminal device, so that the node device calls the smart contract to generate a first parameter hash value for the first input parameter, and matching the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table; receiving a target transaction execution result and a target transaction hash value returned by the node device, wherein the target transaction execution result and the target transaction hash value in the transaction execution table match the target business party identifier with the first business party identifier, the first requester information, and the first parameter hash value; and determining that the target transaction hash value is different from the first transaction hash value.

[0009] This disclosure proposes a node device configured in a blockchain network, where smart contracts are deployed to maintain a transaction execution table. The node device includes: a first transaction request acquisition unit, configured to acquire a first transaction request sent by a terminal device of a first requester, the first transaction request carrying a first business party identifier, first requester information, and a first input parameter for executing the first transaction request; a first parameter hash value generation unit, configured to invoke the smart contract to generate a first parameter hash value for the first input parameter; a transaction execution table matching unit, configured to invoke the smart contract to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table; and a target transaction execution result return unit, configured to return the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester, the target transaction hash value being different from the first transaction hash value of the first transaction request.

[0010] This disclosure provides a terminal device that communicates with a blockchain network. A smart contract is deployed in the blockchain network to maintain a transaction execution table. The terminal device includes: a first transaction request generation unit, used to generate a first transaction request via the terminal device of a first requester. The first transaction request carries a first business party identifier, first requester information, and a first input parameter for executing the first transaction request; a first transaction hash value generation unit, used to generate a first transaction hash value for the first transaction request via the terminal device of the first requester; and a first transaction request sending unit, used to send the first transaction request to a node device in the blockchain network via the terminal device of the first requester, so that the node device calls the smart contract to generate a first parameter hash value for the first input parameter and includes the first business party identifier. The first requester information and the first parameter hash value are matched with the transaction execution table; the target transaction execution result receiving unit is used to receive the target transaction execution result and the target transaction hash value returned by the node device, wherein the target transaction execution result and the target transaction hash value correspond to the target business party identifier, the target requester information and the target parameter hash value in the transaction execution table, and the target business party identifier, the target requester information and the target parameter hash value in the transaction execution table are matched with the first business party identifier, the first requester information and the first parameter hash value respectively; the target transaction hash value determining unit is used to determine that the target transaction hash value is different from the first transaction hash value.

[0011] This disclosure provides an electronic device, including: at least one processor; and a storage device for storing at least one program, which, when executed by the at least one processor, causes the at least one processor to implement the blockchain-based data processing method as described in the above embodiments.

[0012] This disclosure provides a computer-readable medium storing a computer program that, when executed by a processor, implements the blockchain-based data processing method described in the above embodiments.

[0013] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based data processing method provided in the various optional implementations described above.

[0014] In some embodiments of the present disclosure, the technical solutions provided include, on the one hand, deploying a smart contract in the blockchain network to maintain a transaction execution table. When a node device in the blockchain network receives a first transaction request sent by a terminal device of a first requester, it can query the transaction execution table maintained by the smart contract based on the first business party identifier, the first requester information, and the first input parameter used to execute the first transaction request carried in the first transaction request. If it is determined that the transaction execution table matches the first parameter hash value, the first business party identifier, and the first requester information of the first input parameter, the node device can determine that the same business as the first transaction request has been successfully executed before. At this time, the node device does not execute the first transaction request, but instead directly returns the target transaction execution result and the target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester. This avoids the node device from repeatedly executing the same business, ensures that transaction operations for the same business are not repeatedly executed, and ensures the idempotency of business execution. That is, the transaction execution table maintained by the smart contract can guarantee that when multiple different transaction requests for the same business are submitted concurrently, only one business can be successfully executed. On the other hand, the terminal device of the first requester that receives the execution result of the target transaction and the hash value of the target transaction can determine that the same business as the first transaction request has been successfully executed before by determining that the hash value of the target transaction is different from the hash value of the first transaction request.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] Figure 1 This is a schematic diagram of the architecture of a blockchain-based data processing system provided in this embodiment.

[0018] Figure 2 This is a schematic diagram of a blockchain network provided in an embodiment of this disclosure.

[0019] Figure 3 This is a schematic diagram of the structure of a block provided in an embodiment of this disclosure.

[0020] Figure 4 This is a schematic diagram of a new block generation process provided in an embodiment of this disclosure.

[0021] Figure 5 A flowchart illustrating a blockchain-based data processing method according to an embodiment of the present disclosure is shown.

[0022] Figure 6 A flowchart illustrating a blockchain-based data processing method according to another embodiment of this disclosure is shown.

[0023] Figure 7 The illustration shows a schematic flowchart of a blockchain-based data processing method according to an embodiment of the present disclosure.

[0024] Figure 8 A flowchart illustrating a blockchain-based data processing method according to yet another embodiment of this disclosure is shown.

[0025] Figure 9 A flowchart illustrating a blockchain-based data processing method according to yet another embodiment of the present disclosure is shown.

[0026] Figure 10 A block diagram of a node device according to an embodiment of the present disclosure is shown schematically.

[0027] Figure 11 A block diagram of a terminal device according to an embodiment of the present disclosure is shown schematically.

[0028] Figure 12 A schematic diagram of the structure of an electronic device suitable for implementing embodiments of the present disclosure is shown. Detailed Implementation

[0029] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be more thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

[0030] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0031] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in at least one hardware module or integrated circuit, or in different network and / or processor devices and / or microcontroller devices.

[0032] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0033] The blockchain disclosed in this embodiment is a novel application model of computer technologies such as distributed data storage, peer-to-peer (P2P) transmission, consensus mechanisms, and encryption algorithms. Essentially, it is a decentralized database, a series 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 a blockchain underlying platform, a platform product service layer, and an application service layer. A blockchain can consist of multiple linked transaction records (also known as blocks) whose content is protected by cryptography. The distributed ledger linked by the blockchain allows multiple parties to effectively record transactions and permanently verify these transactions (immutable). The consensus mechanism refers to the mathematical algorithm used in the blockchain network to establish trust and acquire rights among different nodes; that is, the consensus mechanism is a mathematical algorithm commonly recognized by all network nodes in the blockchain.

[0034] like Figure 1 As shown, the blockchain-based data processing system provided in this embodiment may include a blockchain network 100 and multiple terminal devices. Figure 1 Taking the example of three terminal devices, namely the first terminal 201, the second terminal 202, and the third terminal 203. Among them, the first terminal 201, the second terminal 202, and the third terminal 203 can be used to obtain transaction data (including transaction requests or transaction data generated after executing transaction requests) from the blockchain network, or to upload transaction data to the blockchain network.

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

[0036] In the blockchain network 100, the node device 101, the first terminal 201, the second terminal 202, and the third terminal 203 can be any electronic device, including but not limited to mobile phones, tablets, laptops, PDAs, smart speakers, mobile internet devices (MIDs), POS (Point of Sales) machines, wearable devices (such as smartwatches, smart bracelets, etc.); it can also be an independent server, a server cluster composed of several servers, or a cloud computing center.

[0037] Each node device 101 in the blockchain network 100 has a corresponding node device identifier. Each node device 101 can also store the node device identifiers of other node devices 101 in the blockchain network 100, so that the generated block can be broadcast to other node devices 101 in the blockchain network 100 based on their node device identifiers. Each node device 101 can maintain a node device identifier list as shown in Table 1, storing the node device name and node device identifier in this list. The node device identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node device; Table 1 only uses IP addresses as an example. N is a positive integer greater than or equal to 1.

[0038] Table 1

[0039] Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0040] Each node device 101 in the blockchain network 100 stores the same blockchain. The blockchain consists of multiple blocks, each block containing the cryptographic hash of the previous block (represented by a hash value calculated using a Merkle tree algorithm), the corresponding timestamp, and transaction data. This design makes the block content difficult to tamper with.

[0041] See Figure 3 A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores transaction data feature values, version number, timestamp, and difficulty value, while the block body stores the transaction data. 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 transaction data 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 transaction data within each block.

[0042] When generating the individual blocks in the blockchain, see Figure 4 When a node device hosting the blockchain receives transaction data, it verifies the data. After verification, it stores the transaction data in a memory pool and updates its hash tree used to record transaction data. Then, it updates the timestamp to the time the transaction data was received and attempts to calculate the feature value multiple times using different random numbers, ensuring that the calculated feature value satisfies the following formula:

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

[0044] 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 transaction data; 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.

[0045] 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 device where the blockchain resides sends the newly generated block to other node devices in the blockchain network 100 according to the node device identifiers of other node devices in the blockchain network 100. The other node devices verify the newly generated block and add it to their stored blockchain after verification.

[0046] Figure 5 A flowchart illustrating a blockchain-based data processing method according to an embodiment of this disclosure is shown schematically. The method provided in this disclosure can be processed by any electronic device with computing power, such as the one described above. Figure 2 Any node device 101 in the embodiment.

[0047] Figure 5 In this embodiment, taking the provided method applied to node device 101 in blockchain network 100 as an example, a smart contract is deployed in blockchain network 100. The smart contract can be used to maintain a transaction execution table, which records relevant information of historically successfully executed transactions. This is used to deduplicatize repeatedly received transaction requests for the same business, prevent the same business from being executed repeatedly, and ensure idempotency.

[0048] Smart contracts are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. They execute the terms of a contract through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to automate transactions, such as checking the logistics status of a buyer's purchase and transferring the buyer's electronic funds to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts that process received information. Smart contracts allow for trusted transactions without a third party; these transactions are traceable and irreversible.

[0049] A smart contract on a blockchain is a contract that can be triggered and executed through transactions on the blockchain. Smart contracts can be defined in the form of code.

[0050] Taking Ethereum as an example, it allows users to create and invoke complex logic within the Ethereum network. As a programmable blockchain, Ethereum's core is the Ethereum Virtual Machine (EVM), which can be run on every Ethereum node. The EVM is a Turing-complete virtual machine that can implement various complex logics. Users publish and invoke smart contracts on Ethereum, which run on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode), so smart contracts deployed on the blockchain can be bytecode.

[0051] Any smart contract in this disclosure embodiment can be deployed to the blockchain network in the following manner, but this disclosure is not limited thereto. After a user sends a transaction containing the creation of a smart contract to the blockchain network, each node can execute this transaction in the EVM. The From field of the transaction records the address of the account that initiated the creation of the smart contract, the Data field stores the contract code (which can be bytecode), and the To field is a null (empty) account value. Once the nodes reach a consensus through the consensus mechanism, the smart contract is successfully created, and users can subsequently call this smart contract.

[0052] After each smart contract is created, a corresponding contract account appears on the blockchain, possessing a specific address. The contract code is stored in the account's storage. The behavior of a smart contract is controlled by the contract code, while the smart contract's storage preserves the contract's state. In other words, smart contracts create virtual accounts on the blockchain containing both contract code and account storage. A smart contract can declare various members, including state variables, functions, function modifiers, and events. State variables are values ​​permanently stored in the smart contract's storage field, used to store the smart contract's state.

[0053] In step S510, a first transaction request sent by the terminal device of the first requester is obtained. The first transaction request carries a first business party identifier, first requester information, and a first input parameter for executing the first transaction request.

[0054] In this embodiment of the disclosure, the first requesting party can be any business party, and the terminal device of the first requesting party can be any terminal device. In the following examples, it is used as... Figure 1 The first terminal 201 in the example is used for illustration, but this disclosure is not limited to this.

[0055] The first terminal 201 can upload a first transaction request to the blockchain network 100. Correspondingly, any node device 101 in the blockchain network 100 can receive the first transaction request sent by the first terminal 201. The first transaction request may carry a first business party identifier, first requester information, and first input parameters.

[0056] The first business party identifier is generated by the first requester before sending the first transaction request. It uniquely identifies the operation object targeted by the first transaction request. For example, if the operation object targeted by the first transaction request is a file in the first dataset, the first business party identifier could be the filename of that file generated by the first requester on the first terminal 201. As another example, if the operation object targeted by the first transaction request is an asset, the first business party identifier could be the identifier of that asset. This disclosure does not limit the form of the first business party identifier, as long as it can uniquely distinguish the operation object targeted by the first transaction request from other operation objects.

[0057] The first requester information may include any identifier that can be used to uniquely distinguish the first requester or the terminal device of the first requester, such as the username of the first requester, the network address of the terminal device of the first requester, the device number, etc.

[0058] The first input parameter may include any input parameters required to execute the first transaction request. For example, if the first transaction request is to transfer 10 electronic resources from account 1 to account 2, the first input parameter may include a first transaction account and a first transaction amount of 10. The first transaction account may include account 1 as the first transfer-out account and account 2 as the first transfer-in account.

[0059] In step S520, the smart contract is invoked to generate the first parameter hash value of the first input parameter.

[0060] Node device 101 can invoke a smart contract to generate a first parameter hash value for the first input parameter using a hash function. The first parameter hash value is a data fingerprint calculated based on the first input parameter passed in the first transaction request.

[0061] The hash function mentioned in the embodiments of this disclosure can be any suitable function such as SHA (Security Hash Algorithm), such as SHA256, SHA3, etc. This disclosure does not limit it.

[0062] In step S530, the smart contract is invoked to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table.

[0063] In some embodiments, if the transaction execution table records the business party identifier, requester information, parameter hash value, transaction execution result, and transaction hash value of historically successfully executed transaction requests, then the first business party identifier, first requester information, and first parameter hash value calculated in the above steps carried in the first transaction request can be compared with the business party identifier, requester information, and parameter hash value of each transaction request already recorded in the transaction execution table. The system queries whether there exists a target business party identifier in the transaction execution table that is the same as the first business party identifier, whether there exists target requester information in the transaction execution table that is the same as the first requester information, and whether there exists a target parameter hash value in the transaction execution table that is the same as the first parameter hash value. If there are matching target business party identifiers, target requester information, and target parameter hash values, then the match is considered successful, meaning that a business transaction identical to the first transaction request has been executed historically. The target transaction execution result and target transaction hash value associated with the target business party identifier, target requester information, and target parameter hash value can be retrieved from the transaction execution table. Otherwise, the match is considered unsuccessful, meaning that a business transaction identical to the first transaction request has not been executed historically.

[0064] In this embodiment of the disclosure, "a business that has historically been executed with the same service as the first transaction request" means that, prior to the first transaction request, a transaction request had been executed that targeted the same operation as the first transaction request, and the transaction operation performed on that operation was also the same. Furthermore, the previously successfully executed transaction request was initiated by the initiator of the first transaction request (the first requester). Specifically, the business party identifier of the previously successfully executed transaction request is the same as the first business party identifier, the requester information is the same as the first requester information, and the input parameters are the same as the first input parameter (determined by checking if the input parameter hash value is the same as the first input parameter hash value). If any of these three parameters is inconsistent, it can be determined that a business that has historically been executed with the same service as the first transaction request has not yet been executed. By associating the business party identifier, requester information, and input parameter hash value of successfully executed transactions with records in the transaction execution table, multiple transaction requests for the same service can be distinguished, satisfying the idempotency requirement, preventing the same service from being executed repeatedly, and ensuring the security and reliability of transaction execution.

[0065] In other embodiments, if the transaction execution table records the business party identifier, platform party identifier, requester information, parameter hash value, transaction execution result, and transaction hash value of historically successfully executed transaction requests, then the node device can assign a first platform party identifier (e.g., denoted as 'a' here) to the operation object targeted by the first transaction request based on the first business party identifier (e.g., 'a' here). The platform party identifier assigned by the node device for the same operation object is the same. If the business party identifier in the different transaction requests received by the node device is the same, then the generated platform party identifier is also the same. That is, the platform party identifier is generated based on the business party identifier, and each platform party identifier is also unique. For example, assuming the first business party identifier is the filename of the operation object is file 1, then the first platform party identifier can be ABC. Then, the node device can compare the first business party identifier, the first requester information, the first parameter hash value calculated in the above steps, and the first platform party identifier generated by the node device carried in the first transaction request with the business party identifier, requester information, parameter hash value, and platform party identifier of each transaction request already recorded in the transaction execution table. It checks whether there is a target business party identifier in the transaction execution table that is the same as the first business party identifier, whether there is target requester information in the transaction execution table that is the same as the first requester information, and whether there is a parameter hash value in the transaction execution table that is the same as the first parameter hash value. The system checks if a target platform identifier exists in the transaction execution table that matches the first platform identifier. If a matching target business identifier, target requester information, target parameter hash value, and target platform identifier exist, the system determines that the match is successful, meaning that the same business as the first transaction request has been executed in the past. The system can then retrieve the target transaction execution result and target transaction hash value associated with the target business identifier, target requester information, target parameter hash value, and target platform identifier from the transaction execution table. Otherwise, the system determines that the match is unsuccessful, meaning that the same business as the first transaction request has not been executed in the past.

[0066] In this embodiment of the disclosure, "having historically executed the same business as the first transaction request" means that, prior to the first transaction request, a transaction request had been executed that was the same as the operation object targeted by the first transaction request and that the transaction operation performed on the operation object was also the same. At the same time, the previously successfully executed transaction request was also initiated by the initiator of the first transaction request (the first requester). That is, the business party identifier of the previously successfully executed transaction request is the same as the first business party identifier, the platform party identifier is the same as the first platform party identifier, the requester information is the same as the first requester information, and the input parameters are the same as the first input parameter (here determined by judging that the input parameter hash value is the same as the first input parameter hash value). If any of the above four parameters is inconsistent, it can be determined that a business that is the same as the first transaction request has not been executed in the past. By associating records in the transaction execution table with the business party identifier, requester information, parameter hash value, and platform identifier of successfully executed transactions, on the one hand, multiple transaction requests for the same business can be distinguished, satisfying idempotency requirements, preventing the same business from being executed repeatedly, and ensuring the security and reliability of transaction execution. On the other hand, by jointly identifying the operation object targeted by the transaction request through the business party identifier and the platform identifier, that is, by having multiple parties maintain the unique identifier of the operation object, rather than solely by the business party, it can be further determined that different transaction requests target the same operation object, further ensuring the security and reliability of transaction execution.

[0067] In some other embodiments, if the transaction execution table records the data entity identifier, requester information, parameter hash value, transaction execution result, and transaction hash value of historically successfully executed transaction requests, the data entity identifier is generated based on the business party identifier and platform party identifier of the successfully executed transaction request. For example, the data entity identifier can be generated by cascading the business party identifier and the platform party identifier, or by calculating the hash value of the business party identifier and the platform party identifier. This disclosure does not limit this. Then, the node device can assign a first platform party identifier to the operation object targeted by the first transaction request based on the first business party identifier. After that, the node device can generate a first data entity identifier based on the first business party platform and the first platform party identifier. The generation method of the first data entity identifier is not limited, as long as it can uniquely distinguish the operation object targeted by the first transaction request. Then, the node device can compare the first data entity identifier, the first requester information, and the first parameter hash value calculated in the above steps of the first transaction request with the data entity identifier, requester information, and parameter hash value of each transaction request already recorded in the transaction execution table. It checks whether there is a target data entity identifier in the transaction execution table that is the same as the first data entity identifier, whether there is target requester information in the transaction execution table that is the same as the first requester information, and whether there is a target parameter hash value in the transaction execution table that is the same as the first parameter hash value. If there are target data entity identifiers, target requester information, and target parameter hash values ​​that match one by one, it is determined that the match is successful, that is, the same business as the first transaction request has been executed in the past. The target transaction execution result and target transaction hash value associated with the target data entity identifier, target requester information, and target parameter hash value can be obtained from the transaction execution table. Otherwise, it is determined that the match is unsuccessful, that is, the same business as the first transaction request has not been executed in the past.

[0068] In this embodiment of the disclosure, a data entity can be understood as an individual of a class of data objects in a dataset. For example, it can be a specific person, thing, or object, or it can be an abstract concept or relationship. The data entity identifier can be used to uniquely distinguish each data entity.

[0069] In this embodiment of the disclosure, "having historically executed the same business as the first transaction request" means that, prior to the first transaction request, a transaction request had been executed that was the same as the operation object targeted by the first transaction request and that the transaction operation performed on the operation object was also the same. At the same time, the previously successfully executed transaction request was also initiated by the initiator of the first transaction request (the first requester). That is, the data entity identifier of the previously successfully executed transaction request is the same as the first data entity identifier, the requester information is the same as the first requester information, and the input parameters are the same as the first input parameter (here determined by judging that the input parameter hash value is the same as the first input parameter hash value). When any of the above three parameters is inconsistent, it can be determined that a business that is the same as the first transaction request has not been executed in the past. By associating the data entity identifier, requester information, and parameter hash value of successfully executed transactions with records in the transaction execution table, on the one hand, multiple transaction requests for the same business can be distinguished, satisfying idempotency requirements, preventing the same business from being executed repeatedly, and ensuring the security and reliability of transaction execution; on the other hand, by generating the data entity identifier of the operation object targeted by the transaction request through the business party identifier and the platform party identifier, that is, the unique identifier of the operation object is maintained by multiple parties, rather than solely by the business party, it can be further determined that different transaction requests target the same operation object, further ensuring the security and reliability of transaction execution.

[0070] In some embodiments, if the transaction execution table records the unique key of the transaction execution table, the transaction execution result, and the transaction hash value of historically successfully executed transaction requests, each unique key is generated based on the data entity identifier, requester information, and parameter hash value of the corresponding transaction request. This unique key is used to uniquely distinguish the same transaction operation performed on the same operation object corresponding to the same data entity identifier, and the same transaction operation is initiated by the same requester. The node device can generate the first unique key of the transaction execution table based on the first data entity identifier, the first requester information, and the first parameter hash value of the first transaction request. Then, the node device can compare the unique key of the first transaction execution table of the first transaction request with the unique keys of the transaction execution tables of each transaction request already recorded in the transaction execution table. It can query whether there is a target transaction execution table unique key that is the same as the unique key of the first transaction execution table. If there is a matching target transaction execution table unique key, it is determined that the match is successful, that is, the same business as the first transaction request has been executed in the past. The target transaction execution result and target transaction hash value associated with the unique key of the target transaction execution table can be obtained from the transaction execution table. Otherwise, it is determined that the match is unsuccessful, that is, the same business as the first transaction request has not been executed in the past.

[0071] In this embodiment of the disclosure, "having historically executed the same business as the first transaction request" means that, prior to the first transaction request, a transaction request had been executed that was the same as the operation object targeted by the first transaction request and that the transaction operation performed on the operation object was also the same. At the same time, the previously successfully executed transaction request was also initiated by the initiator of the first transaction request (the first requester). That is, the previously successfully executed transaction request contained a target transaction execution table unique key that was the same as the unique key of the first transaction execution table. When there is no matching target transaction execution table unique key, it can be determined that the same business as the first transaction request has not been executed in the past. By associating a unique key of the transaction execution table with records of successfully executed transactions, two advantages are achieved. First, multiple transaction requests for the same business can be distinguished, satisfying idempotency requirements, preventing the same business from being executed repeatedly, and ensuring the security and reliability of transaction execution. Second, the unique key of the transaction execution table uniquely identifies a transaction operation initiated by a specific requester for a specific operation object. This unique key is generated based on the corresponding data entity identifier, requester information, and parameter hash value. In other words, multiple parties maintain the unique identifier of the transaction operation initiated by the requester for the operation object, rather than solely by the business party. This further confirms that different transaction requests are initiated by the same initiator for the same operation object, further ensuring the security and reliability of transaction execution.

[0072] In step S540, the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information and the first parameter hash value in the transaction execution table are returned to the terminal device of the first requester. The target transaction hash value is different from the first transaction hash value of the first transaction request.

[0073] In this embodiment of the disclosure, if the transaction execution table contains a target transaction execution result and a target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value of the first transaction request, the node device can determine that the same business as the first transaction request has been successfully executed before. At this time, the node device can directly return the corresponding target transaction execution result and target transaction hash value stored in the transaction execution table to the terminal device of the first requester, without repeating the first transaction request. After receiving the target transaction hash value and target transaction execution result returned by the node device, the terminal of the first requester compares the received target transaction hash value with the first transaction hash value generated on the terminal device of the first requester. If it is determined that the target transaction hash value is different from the first transaction hash value, it can be known that although the target transaction execution result has been received, the target transaction execution result was not obtained by executing the first transaction request, but by a transaction request that has been successfully executed before.

[0074] The first transaction hash value is obtained by the terminal device of the first requester performing a hash operation on the first transaction request after generating it.

[0075] In an exemplary embodiment, returning the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester may include: verifying the legality of the first transaction request; if the first transaction request is legal, generating a first block including the first transaction request; adding the first block to the corresponding blockchain; if the first block is successfully added to the blockchain, retrieving the target business party identifier, target requester information, and target parameter hash value that match the first business party identifier, the first requester information, and the first parameter hash value from the transaction execution table; and returning the target transaction execution result and target transaction hash value corresponding to the target business party identifier, the target requester information, and the target parameter hash value to the terminal device of the first requester.

[0076] In an exemplary embodiment, returning the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester may include: verifying the legality of the first transaction request; if the first transaction request is legal, generating a first block including the first transaction request; adding the first block to the corresponding blockchain; if the first block is successfully added to the blockchain, generating a first platform identifier based on the first business party identifier; generating a first data entity identifier based on the first business party identifier and the first platform identifier; retrieving from the transaction execution table the target data entity identifier, target requester information, and target parameter hash value that match the first data entity identifier, the first requester information, and the first parameter hash value, respectively; and returning the target transaction execution result and target transaction hash value corresponding to the target data entity identifier, the target requester information, and the target parameter hash value to the terminal device of the first requester.

[0077] In an exemplary embodiment, returning the target transaction execution result and target transaction hash value, which match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table, to the terminal device of the first requester may include: verifying the legality of the first transaction request; if the first transaction request is legal, generating a first block including the first transaction request; adding the first block to the corresponding blockchain; if the first block is successfully added to the blockchain, generating a first platform identifier based on the first business party identifier; generating a first data entity identifier based on the first business party identifier and the first platform identifier; generating a first transaction execution table unique key based on the first data entity identifier, the first requester information, and the first parameter hash value; if the first transaction execution table unique key matches the target transaction execution table unique key in the transaction execution table, returning the target transaction execution result and target transaction hash value corresponding to the target transaction execution table unique key to the terminal device of the first requester.

[0078] In this embodiment, node device 101 can receive transaction requests sent by various terminal devices, including a first transaction request sent by a first terminal 201. The received transaction requests are identified as transaction data to be uploaded to the blockchain. Multiple transaction data to be uploaded to the blockchain are stored in a transaction pool, and target transaction data is read from the transaction pool in a certain order. The target transaction data can refer to any of the aforementioned multiple transaction data; here, it is assumed that the target transaction data includes the first transaction request. The target transaction data includes, but is not limited to, electronic resource transfer transaction data, equity transaction data, and fund transaction data. The order may include the time sequence in which the transaction data is cached in the transaction pool, the importance priority of the transaction data, and the transaction type. This facilitates the orderly verification of each transaction data, improving the flexibility and accuracy of the verification.

[0079] In some embodiments, transaction types may include real-time transaction types and non-real-time transaction types. Real-time transaction types may include electronic resource transfers (instantaneous arrival), on-chain electronic certificates, etc.; non-real-time transaction types may include on-chain news data, user registration data, etc. Node device 101 may prioritize reading transaction data of real-time transaction types, and then read transaction data of non-real-time transaction types. This ensures that transaction data of real-time transaction types can be processed in real time.

[0080] In some embodiments, the importance priority can be determined based on the organization to which the transaction data belongs. For example, if the transaction data belongs to an administrative department, its importance priority is higher; conversely, if the transaction data belongs to a company or individual, its importance priority is lower. Importance priority indicates the importance, confidentiality, etc., of the transaction data; that is, the higher the importance priority, the higher the importance and confidentiality of the transaction data; the lower the importance priority, the lower the importance and confidentiality of the transaction data. Therefore, node device 101 can prioritize reading transaction data with high importance priority, and then read transaction data with low importance priority. This ensures that transaction data with high importance priority can be processed in real time, effectively improving the security of transaction data and preventing its leakage.

[0081] In some embodiments, node device 101 can read each transaction data in the transaction pool in the order of the time when each transaction data was received, which can improve the fairness of processing each transaction data.

[0082] When a node device receives a first transaction request sent by a first terminal 201, it can obtain the attribute information of the first transaction request and verify its validity based on that attribute information. Specifically, verifying the validity of the first transaction request can mean: verifying whether the first transaction request can be successfully executed; if it can be successfully executed, the first transaction request is determined to be valid; if it cannot be successfully executed, the first transaction request is determined to be invalid.

[0083] After reading the first transaction request, its attribute information can be obtained. This attribute information includes the first quantity of electronic resources required to predict the execution of the first transaction request, the size of the first transaction request, the signature information of the first transaction request, and the generation time of the first transaction request. In other words, the first quantity can refer to the amount of electronic resources the user is willing to pay to execute the first transaction request. Electronic resources refer to funds used to purchase digital assets, which may include, but are not limited to, electronic tickets, game resources (such as game currency, game equipment, etc.), etc.

[0084] After reading the first transaction request from the transaction pool, the system obtains the first quantity of electronic resources (ERPs) predicted by the user for executing the first transaction request. Then, it obtains the second quantity of ERPs actually required to execute the first transaction request, which is stored in advance. The system compares the first quantity with the second quantity. If the first quantity is greater than the second quantity, the first transaction request is determined to be valid, meaning that the user's predicted ERPs required to execute the first transaction request are greater than the actual ERPs required to execute the first transaction request, and the first transaction request can be executed successfully. If the first quantity is less than or equal to the second quantity, the first transaction request is determined to be invalid, meaning that the user's predicted ERPs required to execute the first transaction request are less than or equal to the actual ERPs required to execute the first transaction request, and the first transaction request cannot be executed successfully.

[0085] In some embodiments, the size of the first transaction request is compared with a pre-set threshold corresponding to the size of the transaction data. If the size of the first transaction request is greater than the threshold, it indicates that there is redundant data in the first transaction request, and the size of the first transaction request does not meet the condition, so the first transaction request is determined to be invalid. If the size of the first transaction request is less than or equal to the threshold corresponding to the size of the transaction data, it indicates that there is no redundant data in the first transaction request, so the first transaction request is determined to be valid.

[0086] In some embodiments, verifying the validity of the first transaction request may refer to: verifying the authenticity and completeness of the first transaction request (i.e., whether it has been tampered with); if the first transaction request is authentic and complete (i.e. has not been tampered with), then the first transaction request is determined to be valid; if the first transaction request is unauthentic or incomplete (i.e. has been tampered with), then the first transaction request is determined to be invalid.

[0087] In some embodiments, node device 101 can obtain the public key corresponding to the first transaction request. The public key corresponding to the first transaction request may refer to the public key of the first terminal 201 that uploaded the first transaction request. The signature information can be verified based on the public key corresponding to the first transaction request. If the verification passes, it indicates that the first transaction request has not been tampered with and has integrity, and the first transaction request is determined to be valid. If the verification fails, it indicates that the first transaction request has been tampered with and does not have integrity, and the first transaction request is determined to be invalid.

[0088] Specifically, when the first transaction request is not uploaded to node device 101, the first terminal 201 can perform a hash operation on the first transaction request to obtain the first transaction hash value of the first transaction request, encrypt the hash value of the first transaction request using a private key, obtain the first transaction request carrying the signature of the first terminal 201, and send the first transaction request and the first transaction request carrying the terminal's signature together to node device 101 of the blockchain network.

[0089] Accordingly, the node device can receive the first transaction request sent by the first terminal 201, carrying the signature of the first terminal 201. The node device can obtain the public key of the first terminal 201 and use it as the public key corresponding to the first transaction request. The node device performs a hash operation on the first transaction request to obtain a first transaction hash value. It then uses the public key to decrypt the first transaction request carrying the signature of the first terminal 201 to obtain a third transaction hash value. The node device compares the first transaction hash value with the third transaction hash value. If the first hash value and the third hash value are different, it indicates that the first transaction request is not complete, that is, the first transaction request has been tampered with, and the first transaction request has not been verified. If the first hash value and the third hash value are the same, it indicates that the first transaction request is complete, that the first transaction request has not been tampered with, and the first transaction request has been verified.

[0090] Among them, the first quantity of electronic resources required to predict the execution of the first transaction request and the generation time of the first transaction request in the attribute information can be used to verify whether the first transaction request can be successfully executed; the size of the first transaction request and the signature information of the first transaction request in the attribute information are used to verify the authenticity and integrity of the first transaction request (i.e., whether it has been tampered with).

[0091] In this embodiment of the disclosure, if the first transaction request is valid, its legitimacy can be further verified. Specifically, the number of node devices in the blockchain network that determine the validity of the first transaction request can be obtained; if the obtained number is greater than a threshold (this threshold can be set according to actual needs, and this disclosure does not limit it), the first transaction request is determined to be legitimate; if the obtained number is less than or equal to the threshold, the first transaction request is determined to be illegitimate.

[0092] It should be noted that once transaction data in the transaction pool has been read, the read transaction data can be deleted from the transaction pool to save storage space and effectively store more new transaction data.

[0093] If the first transaction request is valid and legitimate, indicating that the first transaction request is complete, authentic, or can be successfully executed, and the number of node devices that determine that the first transaction request is valid is greater than the number threshold, then node device 101 can store the first transaction request as target transaction data in a block of the blockchain network (here referred to as the first block).

[0094] For example, suppose node device 101 stores the first transaction request in block 10001. Block 10001 includes a block header and a block body. The block header of block 10001 includes 10000H, 10001H, 10001T, etc., where 10000H represents the hash value of the block header of block 10000 in the blockchain, 10001H represents the hash value corresponding to the transaction data (including the first transaction request, and may also include other transaction data) in the block body of block 10001, and 10001T represents the block generation timestamp of block 10001.

[0095] In an exemplary embodiment, the method may further include: if the first transaction request is not legitimate, or the first block fails to be uploaded to the chain, then returning a first transaction execution result indicating that the first transaction request failed to be executed to the terminal device of the first requester.

[0096] If the first transaction request is invalid or illegitimate, indicating that it lacks completeness, authenticity, or cannot be successfully executed, or if the number of node devices that determine the first transaction request is valid is less than or equal to a certain threshold, then node device 101 can roll back the first transaction request. This avoids storing invalid transaction data in the block, saving block storage space and ensuring the validity of data in the blockchain. Rollback refers to the act of restoring a program or data to its previous correct state after a program or data processing error.

[0097] If the transaction data being read is not valid or legitimate, then the read transaction data will be removed from the transaction pool.

[0098] The blockchain-based data processing method provided in this disclosure, on the one hand, deploys a smart contract in the blockchain network to maintain a transaction execution table. When a node device in the blockchain network receives a first transaction request sent by a terminal device of a first requester, it can query the transaction execution table maintained by the smart contract based on the first business party identifier, the first requester information, and the first input parameters used to execute the first transaction request carried in the first transaction request. If it is determined that the transaction execution table matches the first parameter hash value, the first business party identifier, and the first requester information of the first input parameters, the node device can determine that the same business as the first transaction request has been successfully executed before. At this time, the node device does not execute the first transaction request, but directly returns the target transaction execution result and the target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester. This can avoid the node device from repeatedly executing the same business, ensure that transaction operations for the same business are not repeatedly executed, and ensure the idempotency of business execution. That is, the transaction execution table maintained by the smart contract can guarantee that when multiple different transaction requests for the same business are submitted concurrently, only one business can be successfully executed. On the other hand, the terminal device of the first requester that receives the execution result of the target transaction and the hash value of the target transaction can determine that the same business as the first transaction request has been successfully executed before by determining that the hash value of the target transaction is different from the hash value of the first transaction request.

[0099] Figure 6 A flowchart illustrating a blockchain-based data processing method according to another embodiment of this disclosure is shown. Figure 6 The method provided in the embodiments is the same as described above. Figure 5 The difference between the methods provided in the embodiments is that, before step S510 above, that is, before obtaining the first transaction request sent by the terminal device of the first requester, the method may further include the following steps.

[0100] In step S610, a second transaction request sent by the terminal device of the first requester is obtained. The second transaction request carries the first service provider identifier, the first requester information, and a first input parameter for executing the second transaction request.

[0101] The node device may receive the second transaction request sent by the first terminal 201 before receiving the first transaction request sent by the first terminal 201. The second transaction request carries the same first business party identifier, first requester information and first input parameters as the first transaction request. That is, the first transaction request and the second transaction request are the same transaction operations for the same business initiated by the same first requester.

[0102] In step S620, the smart contract is invoked to calculate and generate the first parameter hash value of the first input parameter.

[0103] After receiving the second transaction request, the node device will use a hash function to generate the first parameter hash value of the first input parameter carried in the second transaction request.

[0104] In step S630, the smart contract is invoked to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table.

[0105] After receiving the second transaction request, the node device will match the first business party identifier, the first requester information, and the first parameter hash value carried in the second transaction request with the transaction execution table. The specific matching method can be referred to the above description of the node device matching the first business party identifier, the first requester information, and the first parameter hash value carried in the first transaction request with the transaction execution table.

[0106] In step S640, if the transaction execution table does not match the first business party identifier, the first requester information, and the first parameter hash value, the smart contract is invoked to obtain the second transaction execution result of the second transaction request.

[0107] In this embodiment of the disclosure, if the transaction execution table matches the first business party identifier, the first requester information and the first parameter hash value carried by the second transaction request, it is similar to the first transaction request described above, indicating that the same business as the second transaction request has been executed before the second transaction request. At this time, the target transaction execution result and target transaction hash value of the business that was successfully executed in the past and is the same as the second transaction request can be returned directly, without the need to execute the second transaction request.

[0108] In some embodiments, the mismatch between the transaction execution table and the first business party identifier, first requester information, and first parameter hash value carried in the second transaction request may be due to the absence of a target business party identifier in the transaction execution table that matches the first business party identifier carried in the second transaction request, the absence of target requester information in the transaction execution table that matches the first requester information carried in the second transaction request, or the absence of a target parameter hash value in the transaction execution table that matches the first parameter hash value carried in the second transaction request.

[0109] In other embodiments, the node device can generate a first platform identifier based on the first business party identifier carried in the second transaction request. If the transaction execution table does not match the first business party identifier, the first requester information, and the first parameter hash value carried in the second transaction request, it may be that there is no target business party identifier in the transaction execution table that matches the first business party identifier carried in the second transaction request, or there is no target platform identifier in the transaction execution table that matches the first platform identifier, or there is no target requester information in the transaction execution table that matches the first requester information carried in the second transaction request, or there is no target parameter hash value in the transaction execution table that matches the first parameter hash value carried in the second transaction request.

[0110] In some other embodiments, the node device can generate a first platform identifier based on the first business party identifier carried in the second transaction request, and then generate a first data entity identifier based on the first business party identifier and the first platform identifier. If the transaction execution table does not match the first business party identifier, the first requester information and the first parameter hash value carried in the second transaction request, it may be that there is no target data entity identifier in the transaction execution table that matches the first data entity identifier of the second transaction request, or there is no target requester information in the transaction execution table that matches the first requester information carried in the second transaction request, or there is no target parameter hash value in the transaction execution table that matches the first parameter hash value carried in the second transaction request.

[0111] In some other embodiments, the node device can generate a first platform identifier based on the first business party identifier carried in the second transaction request, generate a first data entity identifier based on the first business party identifier and the first platform identifier, and generate a first transaction execution table unique key based on the first data entity identifier, the first requester information and the first parameter hash value. If the transaction execution table does not match the first business party identifier, the first requester information and the first parameter hash value carried in the second transaction request, it may be that there is no target transaction execution table unique key in the transaction execution table that matches the first transaction execution table unique key of the second transaction request.

[0112] In an exemplary embodiment, invoking the smart contract to obtain the second transaction execution result of the second transaction request may include: verifying the legality of the second transaction request; if the second transaction request is legal, generating a second block including the second transaction request; adding the second block to the corresponding blockchain; if the second block is successfully added to the blockchain, invoking the smart contract to execute the second transaction request; if the second transaction request is successfully executed, the second transaction execution result is "successfully executed second transaction request".

[0113] The verification method for the legitimacy of the second transaction request can refer to the verification process for the legitimacy of the first transaction request described above.

[0114] It should be noted that although the embodiments of this disclosure are illustrated by first putting a legitimate transaction request (including a first transaction request and a second transaction request) on the blockchain, and then having a node device call a smart contract to execute the transaction request after it has been put on the blockchain to obtain the transaction execution result (including the first transaction execution result, the second transaction execution result and the target transaction execution result), this disclosure is not limited to this.

[0115] In other embodiments, after verifying the legitimacy of the transaction request, the node device may first execute the transaction request to obtain the corresponding transaction execution result, and then package the transaction execution result corresponding to the transaction request to generate a new block before putting it on the chain.

[0116] In other embodiments, after verifying the legitimacy of a transaction request, the node device may upload the legitimate transaction request to the blockchain. Then, the corresponding terminal, such as the second terminal 202, pulls the block corresponding to the transaction request from the blockchain. The second terminal 202 executes the transaction request in the pulled block, obtains the corresponding transaction execution result, and then uploads the transaction execution result as transaction data to the blockchain network. The node devices in the blockchain network package the transaction data, including the transaction execution result, into a block and upload it to the blockchain. For example, if the transaction request in the block involves a transfer, the second terminal 202 could be a banking institution.

[0117] In an exemplary embodiment, calling the smart contract to obtain the second transaction execution result of the second transaction request may further include: if the second block fails to be uploaded to the blockchain, or if the second block is successfully uploaded to the blockchain but the execution of the second transaction request fails, then the second transaction execution result is that the execution of the second transaction request has failed.

[0118] The method may further include: if the second transaction execution result is that the execution of the second transaction request fails, then roll back the successfully executed transaction operation in the second transaction request; and return the second transaction execution result to the terminal device of the first requester.

[0119] When multiple transactions are executed on a blockchain, some transactions may succeed while others fail. This lack of consistency among the transactions reduces the accuracy of the transaction data on the blockchain.

[0120] Blockchain has transactional characteristics, meaning that when multiple transactions are executed on the blockchain, and some transactions succeed while others fail, the successful transactions are rolled back. This allows the blockchain to return to the state before the second transaction request was executed, ensuring the consistency and atomicity of multiple transactions on the blockchain, avoiding inaccurate transaction data, and thus improving the stability of the blockchain.

[0121] Specifically, the node device receives a second transaction request and executes at least one transaction operation corresponding to the second transaction request on the blockchain. If any of the at least one transaction operation fails, the successful transaction operations are rolled back. The following example illustrates this, assuming at least one transaction operation includes both a first and a second transaction operation.

[0122] The first and second transaction operations may include at least one of the following: electronic resource transfer operations on the blockchain, transfer operations of consumer voucher information (which can realize consumer invoices) on the blockchain, authentication and certification operations on the blockchain, logistics anti-counterfeiting and traceability certification operations on the blockchain, and adjustment operations of record tables associated with the blockchain.

[0123] The transfer of electronic resources or consumption voucher information refers to the transfer of electronic resources between accounts on the blockchain; the authentication and certification operation refers to adding rights certificates and other documents to the blockchain (registration), which can be queried from the blockchain later; the logistics anti-counterfeiting and traceability certification operation refers to the recording of the entire process from the production to the sale of goods on the blockchain. Relying on the immutability of blockchain data, it ensures that the information of sold goods is permanently recorded, and the entire process from production to sale is traceable; the transaction record table adjustment operation refers to adjusting the remaining resource amount of all accounts on the blockchain in the transaction record table.

[0124] For example, the first transaction is an electronic resource transfer, and the second transaction is the on-chain storage of proof-of-stake documents. This means that a user pays for certain electronic resources on the blockchain and can store their proof-of-stake documents on the blockchain. Alternatively, the first transaction might be a resource data transfer, and the second transaction might be the on-chain storage of goods and logistics data. This means that a user pays for certain electronic resources on the blockchain and can store the goods' logistics trajectory, production videos, etc., on the blockchain.

[0125] The following explanation uses the first and second trading operations as examples of transfer and adjustment operations, respectively:

[0126] Specifically, if either the first or second trading operation fails, a rollback process is performed on the successful trading operation. This can include: if the first trading operation fails and the second trading operation succeeds, the second trading operation is designated as the target trading operation; if the second trading operation fails and the first trading operation succeeds, the first trading operation is designated as the target trading operation, and a rollback process is performed on the target trading operation. The target trading operation includes a target trading volume and a target trading account. The target trading account includes the transferring-out account and the transferring-in account. The following examples use the second trading operation as the target trading operation for illustration.

[0127] For example, suppose the target transaction operation includes a transfer operation (first transaction operation) and an adjustment operation (second transaction operation). The transfer operation refers to transferring resource data equal to the target transaction volume on the blockchain, and the adjustment operation refers to adjusting the remaining resource amount of the target transaction account in the transaction record table associated with the blockchain. The transaction record table is used to record the remaining resource amount of all transaction accounts on the blockchain.

[0128] The rollback process for the target transaction operation may include: invalidating the target transaction record stored in the target block, where the target block is part of the blockchain and is generated by the transfer operation; updating the remaining resource amount of the target transaction account in the transaction record table according to the target transaction volume; the remaining resource amount of the target transaction account after the update is the same as the remaining resource amount of the target transaction account before the adjustment operation.

[0129] For example, such as Figure 2 As shown, assume that each of the four node devices stores one blockchain entry. Figure 3 As shown, the blockchain is assumed to already include 3 blocks.

[0130] The node device obtains a second transaction request on the blockchain. Suppose that the second transaction request requests the transfer of 10 (target transaction amount) electronic resources from account 1 (transfer-out account) to account 2 (transfer-in account) on the blockchain.

[0131] The node device determines whether Account 1 and Account 2 are accounts on the blockchain, and whether the current length of the blockchain has reached its maximum storage capacity (i.e., whether more data can be written to the blockchain), etc. If it determines that Account 1 and Account 2 are accounts on the blockchain, and that the current length of the blockchain has not reached its maximum storage capacity, the node device can obtain the current remaining resources of the transferring account from the transaction record table. If the current remaining resources of the transferring account are not less than the target transaction amount, a target transaction record corresponding to the second transaction request can be generated.

[0132] If the current remaining resources in the sending account are less than the target transaction amount, or if there is no sending or receiving account on the blockchain, it means that the conditions for electronic resource transfer are not met. The first transaction operation can be determined to have failed, which in turn means that the second transaction request has failed. Other transaction operations in the second transaction request that have not yet started can be stopped.

[0133] For example, if the transaction record table shows that the current remaining resources of account 1 are 40, then the current remaining resources of account 1 are greater than the target transaction amount of 10. Therefore, transferring 10 electronic resources from account 1 to account 2 can generate a target transaction record: (transfer address: account 1; transfer address: account 2; resource amount: 10). The first transaction operation is successfully executed, and the target transaction record for transferring electronic resources is stored on the blockchain.

[0134] The target transaction record is stored in the block body. The Merkle root of the target transaction record is calculated. The hash value of the last block (i.e., the 3rd block) and the current timestamp are obtained. The Merkle root, the hash value of the last block, and the current timestamp are stored in the block header. The block header and the block body containing the target transaction record are combined to form the target block. The newly generated target is added to the blockchain. Once the target transaction record is added to the blockchain, it proves that the transfer of electronic resources has been completed, i.e., the first transaction operation has been successfully executed.

[0135] After the first transaction is successfully executed, the blockchain consists of four blocks. The last block is the newly generated target block, which stores the target transaction record corresponding to the first transaction.

[0136] If it is determined that account 1 or account 2 does not exist on the blockchain, or that the current length of the blockchain has reached the maximum storage capacity, or that the current remaining resources of account 1 are less than 10, then the first transaction operation will fail.

[0137] The second transaction operation can be executed in parallel with the first transaction operation, or it can be executed sequentially. That is, the first transaction operation is executed first and then the second transaction operation is executed, or the second transaction operation is executed first and then the first transaction operation is executed. This can be determined based on whether there is a dependency relationship between the first and second transaction operations.

[0138] If there are both a transfer-out account and a transfer-in account in the transaction record table, and the current remaining resources of the transfer-out account are not less than the target transaction volume, adjust the remaining resources of the transfer-out account and the remaining resources of the transfer-in account according to the second transaction request.

[0139] For example, let's assume the second transaction request is: to transfer 10 electronic resources from account 1 to account 2. The transaction record table shows that the current remaining resources of account 1 are 40 and the current remaining resources of account 2 are 20. The adjustment operation, i.e. the second transaction operation, is to adjust the remaining resources of account 1 to 40-10=30 in the transaction record table and adjust the remaining resources of account 2 to 20+10=30 in the transaction record table.

[0140] If the first transaction operation succeeds but the second transaction operation fails, the node device needs to roll back the successfully executed transaction operation (i.e., the first transaction operation). The specific process for rolling back the first transaction operation is as follows: Since the corresponding target transaction record 1 has been stored on the blockchain after the first transaction operation is successfully executed, the target transaction record on the blockchain needs to be invalidated. If the target block only stores the target transaction record and does not store other transaction records, the newly generated target block can be further set as an invalid block.

[0141] Alternatively, the node device generates a new transaction request (called a rollback transaction request) based on the second transaction request. The transaction account and transaction volume in the rollback transaction request are exactly the same as the target transaction account and target transaction volume in the second transaction request. The difference is that the transfer-in account in the second transaction request is the transfer-out account in the rollback transaction request, and the transfer-out account in the second transaction request is the transfer-in account in the rollback transaction request.

[0142] For example, the second transaction request is: requesting to transfer electronic resources with a resource quantity of 10 from account 1 to account 2, and the rollback transaction request is: requesting to transfer electronic resources with a resource quantity of 10 from account 2 to account 1.

[0143] The node device can execute the transaction operation corresponding to the rollback transaction request. After the transaction operation corresponding to the rollback transaction request is executed, the effect is equivalent to rolling back the transfer operation in the first transaction operation.

[0144] Analysis shows that if the first transaction is not rolled back, it is equivalent to 10 electronic resources appearing out of thin air in account 2, or 10 electronic resources appearing out of thin air on the blockchain. This kind of electronic resource appearing out of thin air due to the inconsistency of multiple transactions is incorrect transaction data on the blockchain. It can be seen that incorrect transaction data will undermine the stability of the blockchain.

[0145] When calculating the remaining resources of account 1 and account 2 based on the blockchain, since the first transaction operation is an invalid block and the target transaction record of the first transaction operation is an invalid transaction record, it is not necessary to traverse the target block when traversing all blocks in the blockchain; or when traversing all blocks in the blockchain, the target transaction record in the target block can be excluded from the statistical scope.

[0146] If the second transaction operation succeeds but the first transaction operation fails, the node device needs to roll back the successfully executed transaction operation (i.e., the second transaction operation). The specific process for rolling back the second transaction operation is as follows:

[0147] The node device obtains the target transaction volume in the second transaction request, and updates the remaining resource volume of the target transaction account in the transaction record table according to the target transaction volume, so that the remaining resource volume of the target transaction account after the update is the same as the remaining resource volume of the target transaction account before the adjustment operation.

[0148] For example, the second transaction request is: to transfer 10 electronic resources from account 1 to account 2. Before the adjustment operation, the remaining resources of account 1 are 20 and the remaining resources of account 2 are 30. After the adjustment operation is successfully executed, the remaining resources of account 1 are 20-10=10 and the remaining resources of account 2 are 30+10=40. The adjustment operation is rolled back, that is, the remaining resources of account 1 are adjusted back to 20:30-10=20 and the remaining resources of account 2 are adjusted back to 30:40-10=30.

[0149] As can be seen from the above, although the second transaction request failed to execute, for the blockchain and accounts 1 and 2 on the blockchain, it is equivalent to returning to the state before the second transaction request was executed, that is, the electronic resources were not transferred out of account 1, nor were the electronic resources transferred into account 2. The multiple transaction operations have consistency and atomicity, which can guarantee the accuracy and integrity of the transaction data on the blockchain.

[0150] It should be noted that the execution of the second transaction request may include multiple transaction operations (e.g., transfer operations and adjustment operations). The second transaction request is considered successful only if all of these multiple transaction operations are executed successfully. Conversely, the second transaction request is considered to have failed if at least one transaction operation fails.

[0151] If either the first or second transaction fails, the successful transaction is rolled back. Rollback ensures consistency across multiple operations on the blockchain, allowing the blockchain to return to its state before the execution of the first and second transactions. This prevents inaccurate transaction data from appearing on the blockchain and improves its stability.

[0152] In step S650, if the second transaction execution result is that the second transaction request is successfully executed, then the second transaction execution result is taken as the target transaction execution result, and the target transaction hash value of the second transaction request is obtained.

[0153] In this embodiment of the disclosure, the target transaction execution result may include indication information indicating the successful execution of the second transaction request, such as "1" indicating successful execution of the second transaction request and "0" indicating failure of the second transaction request, but this disclosure is not limited to this. In other embodiments, the target transaction execution result may also include a specific return value after the successful execution of the second transaction request.

[0154] In this embodiment of the disclosure, there are no limitations on how the node device obtains the target transaction hash value of the second transaction request.

[0155] In some embodiments, the node device may use a hash function to calculate the second transaction request and obtain the target transaction hash value.

[0156] In other embodiments, if the first terminal 201 performs a hash operation on the second transaction request when generating the second transaction request to obtain the second transaction hash value of the second transaction request, and encrypts the hash value of the second transaction request using a private key to obtain a second transaction request carrying the signature of the first terminal 201, and then sends the second transaction request and the second transaction request carrying the signature of the first terminal together to the node device of the blockchain network, then after receiving the second transaction request and the second transaction request carrying the signature of the first terminal, the node device can obtain the public key of the first terminal 201, and use the public key to decrypt the second transaction request carrying the signature of the first terminal to obtain the target transaction hash value.

[0157] In step S660, the smart contract is invoked to associate and store the first business party identifier, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value in the transaction execution table.

[0158] In this embodiment of the disclosure, after the second transaction request is successfully executed, the first business party identifier, the first requester information, and the first parameter hash value carried by the second transaction request, as well as the corresponding target transaction execution result and target transaction hash value, can be stored in the transaction execution table. This table is used to filter and deduplicate subsequent transaction requests that target the same business as the second transaction request, prevent duplicate execution, and ensure idempotency.

[0159] In some embodiments, the first business party identifier, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value are associated and stored in the transaction execution table. Alternatively, the first business party identifier, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value can be directly stored in the transaction execution table, with the first business party identifier serving as the target business party identifier, the first requester information serving as the target requester information, and the first parameter hash value serving as the target parameter hash value.

[0160] In other embodiments, the node device can generate a first platform identifier for the second transaction request based on the first business party identifier in the second transaction request. Specifically, the first business party identifier, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value are associated and stored in the transaction execution table. This means that the first business party identifier, the first platform identifier, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value of the second transaction request can be stored in the transaction execution table, with the first business party identifier serving as the target business party identifier, the first platform identifier serving as the target platform identifier, the first requester information serving as the target requester information, and the first parameter hash value serving as the target parameter hash value.

[0161] In some other embodiments, the node device can generate a first platform identifier based on the first business party identifier carried in the second transaction request, and then generate a first data entity identifier based on the first business party identifier and the first platform identifier. The first business party identifier, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value are associated and stored in the transaction execution table. Alternatively, the first data entity identifier of the second transaction request, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value can be stored in the transaction execution table, with the first data entity identifier serving as the target data entity identifier, the first requester information serving as the target requester information, and the first parameter hash value serving as the target parameter hash value.

[0162] In some embodiments, the node device can generate a first platform identifier based on the first business party identifier carried in the second transaction request, generate a first data entity identifier based on the first business party identifier and the first platform identifier, generate a first transaction execution table unique key based on the first data entity identifier, the first requester information and the first parameter hash value, and associate and store the first business party identifier, the first requester information, the first parameter hash value, the target transaction execution result and the target transaction hash value in the transaction execution table. The first transaction execution table unique key of the second transaction request, the target transaction execution result and the target transaction hash value can be stored in the transaction execution table, and the first transaction execution table unique key serves as the target transaction execution table unique key.

[0163] In step S670, the target transaction execution result and the target transaction hash value are returned to the terminal device of the first requester, and the target transaction hash value is the same as the second transaction hash value of the second transaction request.

[0164] Specifically, when the second transaction request is not uploaded to node device 101, the first terminal 201 can perform a hash operation on the second transaction request to obtain the second transaction hash value. When the node device returns the target transaction hash value obtained from successfully executing the second transaction request to the first terminal, the first terminal can compare the received target transaction hash value with the second transaction hash value. If they match, it can be determined that the received target transaction execution result is a successful return of the second transaction request, and that the same business as the second transaction request has not been executed in the past.

[0165] Figure 7 The illustration schematically shows a flowchart of a blockchain-based data processing method according to an embodiment of the present disclosure. Figure 7 As shown, the steps may include the following.

[0166] In step S710, the transaction is submitted.

[0167] In this embodiment of the disclosure, transaction submission can refer to a transaction request sent by any terminal device to a node device in the blockchain network, which may include the first transaction request and the second transaction request sent by the first terminal 201 to the node device 101.

[0168] In any transaction request sent by a terminal device to a node device in the blockchain network, a business party identifier is specified. For example, the first transaction request specified a first business party identifier, and the second transaction request also specified a first business party identifier, in order to distinguish which operation object each transaction request is targeting.

[0169] In step S720, the blockchain core 710 performs duplicate transaction filtering.

[0170] In this embodiment of the disclosure, after the blockchain network receives a transaction request sent by any terminal device, it can use the transaction execution table maintained by the smart contract to filter the received transaction request for duplicate transactions. Here, duplicate transaction filtering means determining whether the currently received transaction request has been successfully executed and recorded in the transaction execution table before, so as to prevent transaction requests for the same business from being executed repeatedly.

[0171] Specifically, step S720 may further include the following steps performed by business contract 720.

[0172] In this embodiment of the disclosure, business contract 720 is the smart contract described above used to maintain the transaction execution table.

[0173] In step S721, the transaction execution table is queried.

[0174] The node device can call business contract 720 to query the transaction execution table to determine whether the business targeted by the currently received transaction request has been successfully executed in the past.

[0175] In step S722, the hash values ​​of historically successfully executed transactions and the business results are returned.

[0176] If, by querying the transaction execution table, it is found that the currently received transaction request has been successfully executed in the past, the node device can directly return the hash value of the historically successfully executed transaction and the business result to the terminal device that sent the transaction request.

[0177] For example, when a node device receives the first transaction request, it can query the transaction execution table to find a target business party identifier, target requester information, and target input parameters that match the first business party identifier, first requester information, and first input parameters (or first input parameter hash value) carried in the first transaction request. Then, it can return the target transaction execution result (business result) and target transaction hash value (historical successful transaction hash value) that match the target business party identifier, target requester information, and target input parameters in the transaction execution table to the first terminal.

[0178] In step S723, the business is executed.

[0179] If, by querying the transaction execution table, it is found that the currently received transaction request has not been successfully executed in the past, the node device can execute the business corresponding to the currently received transaction request.

[0180] In step S724, if the execution is successful, the transaction is written to the transaction execution table.

[0181] For example, when a node device receives a second transaction request, it queries the transaction execution table and finds that there is a target business party identifier, target requester information, and target input parameter that match the first business party identifier, first requester information, and first input parameter (or first input parameter hash value) carried in the second transaction request. Then, the node device executes the second transaction request, obtains the target transaction execution result and target transaction hash value of the second transaction request, and uses the first business party identifier, first requester information, and first input parameter hash value carried in the second transaction request as the target business party identifier, target requester information, and target input parameter hash value, respectively. The target business party identifier, target requester information, target input parameter hash value, target transaction execution result, and target transaction hash value are associated and stored in the transaction execution table.

[0182] In step S725, if the execution fails or the transaction execution table is not written, a rollback is performed.

[0183] For example, if the node device fails to execute the second transaction request, or fails to associate and store the target business party identifier, target requester information, target parameter hash value, target transaction execution result, and target transaction hash value of the successfully executed second transaction request in the transaction execution table, a failure rollback will be performed. The specific rollback process can be referred to the above embodiment.

[0184] In step S726, the process returns to the previous step. Specifically, in step S727, the hash value of the currently successfully executed transaction and the business result are returned.

[0185] For example, if the execution is successful and the target business party identifier, target requester information, target parameter hash value, target transaction execution result, and target transaction hash value of the second transaction request are successfully associated and stored in the transaction execution table, then the target transaction execution result (business result) and target transaction hash value (currently successfully executed transaction hash value) are returned to the first terminal.

[0186] Figure 8 The illustration shows a schematic flowchart of a blockchain-based data processing method according to an embodiment of the present disclosure. Figure 8 The method provided in the embodiments can be applied to terminal devices that communicate with a blockchain network, where smart contracts are deployed to maintain a transaction execution table.

[0187] Figure 8 The method provided in the embodiments may include the following steps.

[0188] In step S810, a first transaction request is generated by the terminal device of the first requester. The first transaction request carries a first business party identifier, first requester information, and a first input parameter for executing the first transaction request.

[0189] In step S820, the first transaction hash value of the first transaction request is generated by the terminal device of the first requester.

[0190] In step S830, the first transaction request is sent from the terminal device of the first requester to the node device in the blockchain network, so that the node device calls the smart contract to generate the first parameter hash value of the first input parameter, and matches the first business party identifier, the first requester information and the first parameter hash value with the transaction execution table.

[0191] In step S840, the target transaction execution result and target transaction hash value returned by the node device are received, wherein the target transaction execution result and target transaction hash value in the transaction execution table are matched with the target business party identifier, the first business party identifier, the first requester information, and the first parameter hash value.

[0192] In step S850, it is determined that the target transaction hash value is different from the first transaction hash value.

[0193] Figure 9 A flowchart illustrating a blockchain-based data processing method according to yet another embodiment of this disclosure is shown. Figure 9 The method provided in the embodiments is the same as described above. Figure 8 The difference between the methods provided in the embodiments is that, before step S810 above, that is, before generating the first transaction request through the terminal device of the first requester, the method may further include the following steps.

[0194] In step S910, a second transaction request is generated through the terminal device of the first requester. The second transaction request carries the first business party identifier, the first requester information, and a first input parameter for executing the second transaction request.

[0195] In step S920, the second transaction hash value of the second transaction request is generated by the terminal device of the first requester.

[0196] In step S930, the second transaction request is sent from the terminal device of the first requester to the node device in the blockchain network, so that the node device calls the smart contract to generate the first parameter hash value of the first input parameter. If the transaction execution table does not match the first business party identifier, the first requester information and the first parameter hash value, the second transaction request is successfully executed, and the second transaction execution result and the second transaction hash value are obtained. The first business party identifier, the first requester information, the first parameter hash value, the second transaction execution result and the second transaction hash value are associated and stored in the transaction execution table, wherein the second transaction execution result is used as the target transaction execution result and the second transaction hash value is used as the target transaction hash value.

[0197] In step S940, the terminal device of the first requester receives the target transaction execution result and the target transaction hash value returned by the node device.

[0198] In step S950, it is determined that the target transaction hash value is the same as the second transaction hash value.

[0199] Blockchain features permanent data storage, immutability, and traceability. Furthermore, blockchain operates on a transaction-by-transaction basis, managing on-chain requests through a transaction pool. Theoretically, the execution time of any submitted transaction is unpredictable, and transactions cannot be submitted and executed repeatedly. Additionally, all on-chain operations are transactional; otherwise, a transaction would either succeed entirely or fail entirely and be rolled back, preventing scenarios where some operations fail.

[0200] This disclosure provides a blockchain-based data processing method that addresses the idempotency problem of business requests based on blockchain smart contracts. By using a transaction execution table, it ensures that even when multiple transactions with the same business are executed concurrently, only one transaction will succeed. It identifies transaction requests in different blocks corresponding to the same business and ensures that different transaction requests for the same business are not executed repeatedly. Users can retry multiple on-chain requests based on the business party identifier carried in the transaction request without worrying about duplicate submissions, thus ensuring idempotency. Through this idempotency guarantee, business parties connecting to the blockchain network can avoid errors such as timeouts or lost responses caused by the asynchronous on-chain nature of blockchain. Multiple request retries can be performed by specifying the business party identifier, reducing the development and integration costs for business parties.

[0201] The following describes relevant device embodiments of this disclosure, which can be used to execute the blockchain-based data processing method described above. For details not disclosed in the relevant device embodiments of this disclosure, please refer to the embodiments of the blockchain-based data processing method described above.

[0202] Figure 10 A block diagram of a node device according to an embodiment of the present disclosure is illustrated. The node device is configured in a blockchain network in which smart contracts are deployed for maintaining a transaction execution table.

[0203] Reference Figure 10 As shown, a node device 1000 according to an embodiment of the present disclosure may include: a first transaction request acquisition unit 1010, a first parameter hash value generation unit 1020, a transaction execution table matching unit 1030, and a target transaction execution result return unit 1040.

[0204] In this embodiment, the first transaction request acquisition unit 1010 can be used to acquire a first transaction request sent by the terminal device of the first requester. The first transaction request carries a first business party identifier, first requester information, and a first input parameter for executing the first transaction request. The first parameter hash value generation unit 1020 can be used to call the smart contract to generate a first parameter hash value for the first input parameter. The transaction execution table matching unit 1030 can be used to call the smart contract to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table. The target transaction execution result return unit 1040 can be used to return the target transaction execution result and the target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester. The target transaction hash value is different from the first transaction hash value of the first transaction request.

[0205] In an exemplary embodiment, the target transaction execution result return unit 1040 may include: a first legality verification unit, which can be used to verify the legality of the first transaction request; a first block generation unit, which, if the first transaction request is legal, generates a first block including the first transaction request; a first block on-chain unit, which can be used to add the first block to the corresponding blockchain; a target parameter retrieval unit, which, if the first block is successfully on-chain, retrieves from the transaction execution table the target business party identifier, target requester information, and target parameter hash value that respectively match the first business party identifier, the first requester information, and the first parameter hash value; and a first target transaction execution result return unit, which can be used to return the target transaction execution result and target transaction hash value corresponding to the target business party identifier, the target requester information, and the target parameter hash value to the terminal device of the first requester.

[0206] In an exemplary embodiment, the target transaction execution result return unit 1040 may include: a second legality verification unit, which can be used to verify the legality of the first transaction request; a first block acquisition unit, which is used to generate a first block including the first transaction request if the first transaction request is legal; a first block addition unit, which can be used to add the first block to the corresponding blockchain; a first platform identifier generation unit, which can be used to generate a first platform identifier based on the first business identifier if the first block is successfully uploaded to the blockchain; a first data entity identifier generation unit, which can be used to generate a first data entity identifier based on the first business identifier and the first platform identifier; a target parameter query unit, which can be used to retrieve from the transaction execution table a target data entity identifier, target requester information, and target parameter hash value that respectively match the first data entity identifier, the first requester information, and the first parameter hash value; and a second target transaction execution result return unit, which can be used to return the target transaction execution result and target transaction hash value corresponding to the target data entity identifier, the target requester information, and the target parameter hash value to the terminal device of the first requester.

[0207] In an exemplary embodiment, the target transaction execution result return unit 1040 may include: a third legality verification unit, which can be used to verify the legality of the first transaction request; a first block acquisition unit, which is used to generate a first block including the first transaction request if the first transaction request is legal; a first block addition unit, which can be used to add the first block to the corresponding blockchain; a first platform identifier acquisition unit, which can be used to generate a first platform identifier based on the first business party identifier if the first block is successfully uploaded to the blockchain; a first data entity identifier acquisition unit, which can be used to generate a first data entity identifier based on the first business party identifier and the first platform identifier; a first transaction execution table unique key generation unit, which can be used to generate a first transaction execution table unique key based on the first data entity identifier, the first requester information, and the first parameter hash value; and a third target transaction execution result return unit, which can be used to return the target transaction execution result and the target transaction hash value corresponding to the target transaction execution table unique key to the terminal device of the first requester if the first transaction execution table unique key matches the target transaction execution table unique key in the transaction execution table.

[0208] In an exemplary embodiment, the node device 1000 may further include: a first transaction execution result return unit, which can be used to return a first transaction execution result indicating failure to execute the first transaction request to the terminal device of the first requester if the first transaction request is not legitimate or the first block fails to be uploaded to the chain.

[0209] In an exemplary embodiment, the node device 1000 may further include: a second transaction request acquisition unit, configured to acquire a second transaction request sent by the terminal device of the first requester before acquiring a first transaction request sent by the terminal device of the first requester, wherein the second transaction request carries the first business party identifier, the first requester information, and a first input parameter for executing the second transaction request; a first parameter hash value acquisition unit, configured to call the smart contract to calculate and generate a first parameter hash value of the first input parameter; a second transaction request matching unit, configured to call the smart contract to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table; and a second transaction execution result acquisition unit, configured to acquire a second transaction result if the transaction execution table matches the first business party identifier, the first requester information, and the first parameter hash value. If the hash values ​​of the transmitted parameters do not match, the smart contract is invoked to obtain the second transaction execution result of the second transaction request; the target transaction hash value acquisition unit can be used to take the second transaction execution result as the target transaction execution result and obtain the target transaction hash value of the second transaction request if the second transaction execution result is a successful execution of the second transaction request; the target parameter association storage unit can be used to invoke the smart contract to associate and store the first business party identifier, the first requester information, the first transmitted parameter hash value, the target transaction execution result and the target transaction hash value in the transaction execution table; the target transaction hash value return unit can be used to return the target transaction execution result and the target transaction hash value to the terminal device of the first requester, wherein the target transaction hash value is the same as the second transaction hash value of the second transaction request.

[0210] In an exemplary embodiment, the second transaction execution result acquisition unit may include: a second transaction request legality verification unit, which can be used to verify the legality of the second transaction request; a second block generation unit, which can be used to generate a second block including the second transaction request if the second transaction request is legal; a second block on-chain unit, which can be used to add the second block to the corresponding blockchain; a second transaction request execution unit, which can be used to call the smart contract to execute the second transaction request if the second block is successfully on-chain; and a second transaction request successful execution result acquisition unit, which can be used to determine the second transaction execution result as successful execution of the second transaction request if the second transaction request is successfully executed.

[0211] In an exemplary embodiment, the second transaction execution result acquisition unit may further include: a second transaction request execution failure result acquisition unit, which can be used to determine the second transaction execution result as "execution of the second transaction request failed" if the second block fails to be uploaded to the chain, or if the second block is successfully uploaded to the chain but the execution of the second transaction request fails.

[0212] In an exemplary embodiment, the node device 1000 may further include: an operation rollback unit, which can be used to roll back the successfully executed transaction operation in the second transaction request if the second transaction execution result is that the execution of the second transaction request fails; and a second transaction execution result return unit, which can be used to return the second transaction execution result to the terminal device of the first requester.

[0213] Figure 11 A block diagram of a terminal device according to an embodiment of the present disclosure is illustrated. The terminal device communicates with a blockchain network in which smart contracts are deployed for maintaining a transaction execution table.

[0214] Reference Figure 11 As shown, a terminal device 1100 according to an embodiment of the present disclosure may include: a first transaction request generation unit 1110, a first transaction hash value generation unit 1120, a first transaction request sending unit 1130, a target transaction execution result receiving unit 1140, and a target transaction hash value determination unit 1150.

[0215] In this embodiment, the first transaction request generation unit 1110 can be used to generate a first transaction request through the terminal device of the first requester. The first transaction request carries a first business party identifier, first requester information, and a first input parameter for executing the first transaction request. The first transaction hash value generation unit 1120 can be used to generate a first transaction hash value for the first transaction request through the terminal device of the first requester. The first transaction request sending unit 1130 can be used to send the first transaction request to a node device in the blockchain network through the terminal device of the first requester, so that the node device calls the smart contract to generate a first parameter hash value for the first input parameter, and matches the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table. The target transaction execution result receiving unit 1140 can be used to receive the target transaction execution result and the target transaction hash value returned by the node device, wherein the target transaction execution result and the target transaction hash value in the transaction execution table match the target business party identifier with the first business party identifier, the first requester information, and the first parameter hash value. The target transaction hash value determining unit 1150 can be used to determine that the target transaction hash value is different from the first transaction hash value.

[0216] In an exemplary embodiment, the terminal device 1100 may further include: a second transaction request generation unit, configured to generate a second transaction request through the terminal device of the first requester before generating a first transaction request through the terminal device of the first requester, wherein the second transaction request carries the first business party identifier, the first requester information, and a first input parameter for executing the second transaction request; a second transaction hash value generation unit, configured to generate a second transaction hash value for the second transaction request through the terminal device of the first requester; and a second transaction request sending unit, configured to send the second transaction request to a node device in the blockchain network through the terminal device of the first requester, so that the node device calls the smart contract to generate a first parameter hash value for the first input parameter, wherein if the transaction execution table is consistent with the first transaction request, the second transaction request is generated by the first transaction requester's terminal device. If the first business party identifier, the first requester information, and the first parameter hash value do not match, the second transaction request is successfully executed, and a second transaction execution result and a second transaction hash value are obtained. The first business party identifier, the first requester information, the first parameter hash value, the second transaction execution result, and the second transaction hash value are associated and stored in the transaction execution table, wherein the second transaction execution result is used as the target transaction execution result, and the second transaction hash value is used as the target transaction hash value. The target transaction execution result hash value receiving unit can be used to receive the target transaction execution result and the target transaction hash value returned by the node device through the terminal device of the first requester. The target transaction hash value same determination unit can be used to determine that the target transaction hash value and the second transaction hash value are the same.

[0217] Figure 12 A schematic diagram of an electronic device suitable for implementing embodiments of the present disclosure is shown. It should be noted that... Figure 12 The illustrated electronic device 1200 is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0218] like Figure 12 As shown, the electronic device 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1202 or a program loaded from a storage section 1208 into a random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0219] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0220] In particular, according to embodiments of this disclosure, the processes described below with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0221] It should be noted that the computer-readable medium disclosed herein may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having at least one wire, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0222] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing at least one executable instruction for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0223] The modules and / or units and / or sub-units described in the embodiments of this disclosure can be implemented in software or hardware, and the described modules and / or units and / or sub-units can also be located in a processor. The names of these modules and / or units and / or sub-units do not, in some cases, constitute a limitation on the module and / or unit and / or sub-unit itself.

[0224] On the other hand, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to perform the methods described in the following embodiments. For example, the electronic device may perform... Figure 5 or Figure 6 or Figure 7 or Figure 8 or Figure 9 The steps shown.

[0225] It should be noted that although several modules, units, or sub-units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules, units, or sub-units described above can be embodied in one module, unit, or sub-unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules, units, or sub-units.

[0226] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this disclosure.

Claims

1. A data processing method based on blockchain, characterized in that, The method is applied to node devices in a blockchain network, where smart contracts are deployed. These smart contracts maintain a transaction execution table, which records information related to historically successfully executed transactions. The method includes: The system obtains a first transaction request sent by the terminal device of the first requester. The first transaction request carries a first business party identifier, first requester information, and a first input parameter for executing the first transaction request. The first business party identifier is used to uniquely identify the operation object targeted by the first transaction request. The smart contract is invoked to generate the first parameter hash value of the first input parameter; The smart contract is invoked to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table. The target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information and the first parameter hash value in the transaction execution table are returned to the terminal device of the first requester. The target transaction hash value is different from the first transaction hash value of the first transaction request.

2. The method as described in claim 1, characterized in that, Returning the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester, including: Verify the legality of the first transaction request; If the first transaction request is valid, a first block including the first transaction request is generated; Add the first block to the corresponding blockchain; If the first block is successfully uploaded to the blockchain, the target business party identifier, target requester information, and target parameter hash value that match the first business party identifier, the first requester information, and the first parameter hash value are retrieved from the transaction execution table. The target transaction execution result and target transaction hash value corresponding to the target business party identifier, the target requester information and the target parameter hash value are returned to the terminal device of the first requester.

3. The method as described in claim 1, characterized in that, Returning the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester, including: Verify the legality of the first transaction request; If the first transaction request is valid, a first block including the first transaction request is generated; Add the first block to the corresponding blockchain; If the first block is successfully uploaded to the blockchain, a first platform identifier is generated based on the first business party identifier. A first data entity identifier is generated based on the first business party identifier and the first platform party identifier; Retrieve from the transaction execution table the target data entity identifier, target requester information, and target parameter hash value that respectively match the first data entity identifier, the first requester information, and the first parameter hash value; The target transaction execution result and target transaction hash value corresponding to the target data entity identifier, the target requester information and the target parameter hash value are returned to the terminal device of the first requester.

4. The method as described in claim 1, characterized in that, Returning the target transaction execution result and target transaction hash value that match the first business party identifier, the first requester information, and the first parameter hash value in the transaction execution table to the terminal device of the first requester, including: Verify the legality of the first transaction request; If the first transaction request is valid, a first block including the first transaction request is generated; Add the first block to the corresponding blockchain; If the first block is successfully uploaded to the blockchain, a first platform identifier is generated based on the first business party identifier. A first data entity identifier is generated based on the first business party identifier and the first platform party identifier; Generate a unique key for the first transaction execution table based on the first data entity identifier, the first requester information, and the first parameter hash value; If the unique key of the first transaction execution table matches the unique key of the target transaction execution table in the transaction execution table, then the target transaction execution result and the target transaction hash value corresponding to the unique key of the target transaction execution table will be returned to the terminal device of the first requester.

5. The method according to any one of claims 2 to 4, characterized in that, Also includes: If the first transaction request is not legitimate, or the first block fails to be uploaded to the blockchain, the first transaction execution result of the failure to execute the first transaction request is returned to the terminal device of the first requester.

6. The method as described in claim 1, characterized in that, Before obtaining the first transaction request sent by the terminal device of the first requester, the method further includes: Obtain a second transaction request sent by the terminal device of the first requester, wherein the second transaction request carries the first business party identifier, the first requester information, and a first input parameter for executing the second transaction request; The smart contract is invoked to calculate and generate the first parameter hash value of the first input parameter; The smart contract is invoked to match the first business party identifier, the first requester information, and the first parameter hash value with the transaction execution table. If the transaction execution table does not match the first business party identifier, the first requester information, and the first parameter hash value, then the smart contract is invoked to obtain the second transaction execution result of the second transaction request; If the second transaction execution result is a successful execution of the second transaction request, then the second transaction execution result is taken as the target transaction execution result, and the target transaction hash value of the second transaction request is obtained; The smart contract is invoked to associate and store the first business party identifier, the first requester information, the first parameter hash value, the target transaction execution result, and the target transaction hash value in the transaction execution table; The execution result of the target transaction and the target transaction hash value are returned to the terminal device of the first requester, wherein the target transaction hash value is the same as the second transaction hash value of the second transaction request.

7. The method as described in claim 6, characterized in that, Calling the smart contract to obtain the second transaction execution result of the second transaction request includes: Verify the legality of the second transaction request; If the second transaction request is valid, a second block including the second transaction request is generated; Add the second block to the corresponding blockchain; If the second block is successfully uploaded to the blockchain, the smart contract is invoked to execute the second transaction request; If the second transaction request is successfully executed, the result of the second transaction execution is that the second transaction request has been successfully executed.

8. The method as described in claim 7, characterized in that, The method of invoking the smart contract to obtain the second transaction execution result of the second transaction request also includes: If the second block fails to be uploaded to the blockchain, or if the second block is successfully uploaded to the blockchain but the execution of the second transaction request fails, then the result of the second transaction execution is that the execution of the second transaction request failed. The method further includes: If the execution result of the second transaction is that the execution of the second transaction request fails, then the successfully executed transaction operation in the second transaction request will be rolled back; The result of the second transaction execution is returned to the terminal device of the first requester.

9. A data processing method based on blockchain, characterized in that, The method is applied to a terminal device communicating with a blockchain network, in which smart contracts are deployed. These smart contracts maintain a transaction execution table, which records relevant information about historically successfully executed transactions. The method includes: A first transaction request is generated through the terminal device of the first requester. The first transaction request carries a first business party identifier, first requester information and a first input parameter for executing the first transaction request. The first business party identifier is used to uniquely identify the operation object targeted by the first transaction request. The first transaction hash value of the first transaction request is generated through the terminal device of the first requester; The first requester's terminal device sends the first transaction request to the node device in the blockchain network, so that the node device calls the smart contract to generate the first parameter hash value of the first input parameter, and matches the first business party identifier, the first requester information and the first parameter hash value with the transaction execution table. The node device returns the target transaction execution result and the target transaction hash value, wherein the target transaction execution result and the target transaction hash value in the transaction execution table match the target business party identifier with the first business party identifier, the first requester information and the first parameter hash value. It is determined that the target transaction hash value is different from the first transaction hash value.

10. The method as described in claim 9, characterized in that, Before generating the first transaction request through the terminal device of the first requester, the method further includes: A second transaction request is generated through the terminal device of the first requester. The second transaction request carries the first business party identifier, the first requester information, and a first input parameter for executing the second transaction request. The second transaction hash value of the second transaction request is generated through the terminal device of the first requester; The second transaction request is sent from the terminal device of the first requester to the node device in the blockchain network, so that the node device calls the smart contract to generate the first parameter hash value of the first input parameter. If the transaction execution table does not match the first business party identifier, the first requester information and the first parameter hash value, the second transaction request is successfully executed, and the second transaction execution result and the second transaction hash value are obtained. The first business party identifier, the first requester information, the first parameter hash value, the second transaction execution result and the second transaction hash value are associated and stored in the transaction execution table, wherein the second transaction execution result is used as the target transaction execution result and the second transaction hash value is used as the target transaction hash value. The terminal device of the first requester receives the target transaction execution result and the target transaction hash value returned by the node device; The target transaction hash value is determined to be the same as the second transaction hash value.

11. A node device, the node device being configured in a blockchain network, the blockchain network deploying smart contracts, the smart contracts being used to maintain a transaction execution table, the transaction execution table being used to record relevant information of historically successfully executed transactions; wherein, The node device includes: The first transaction request acquisition unit is used to acquire the first transaction request sent by the terminal device of the first requester. The first transaction request carries the first business party identifier, the first requester information and the first input parameter for executing the first transaction request. The first business party identifier is used to uniquely identify the operation object targeted by the first transaction request. The first parameter hash value generation unit is used to call the smart contract to generate the first parameter hash value of the first input parameter; The transaction execution table matching unit is used to call the smart contract to match the first business party identifier, the first requester information and the first parameter hash value with the transaction execution table. The target transaction execution result return unit is used to return the target transaction execution result and the target transaction hash value that match the first business party identifier, the first requester information and the first parameter hash value in the transaction execution table to the terminal device of the first requester. The target transaction hash value is different from the first transaction hash value of the first transaction request.

12. A terminal device, characterized in that, The terminal device communicates with a blockchain network, in which smart contracts are deployed. These smart contracts maintain a transaction execution table, which records information related to historically successfully executed transactions. The terminal device includes: The first transaction request generation unit is used to generate a first transaction request through the terminal device of the first requester. The first transaction request carries a first business party identifier, first requester information and a first input parameter for executing the first transaction request. The first business party identifier is used to uniquely identify the operation object targeted by the first transaction request. The first transaction hash value generation unit is used to generate the first transaction hash value of the first transaction request through the terminal device of the first requester; The first transaction request sending unit is used to send the first transaction request to the node device in the blockchain network through the terminal device of the first requester, so that the node device calls the smart contract to generate the first parameter hash value of the first input parameter, and matches the first business party identifier, the first requester information and the first parameter hash value with the transaction execution table. The target transaction execution result receiving unit is used to receive the target transaction execution result and the target transaction hash value returned by the node device, wherein the target transaction execution result and the target transaction hash value in the transaction execution table are matched with the target business party identifier and the first business party identifier, the first requester information and the first parameter hash value; A target transaction hash value determination unit is used to determine that the target transaction hash value is different from the first transaction hash value.

13. An electronic device, characterized in that, include: At least one processor; Storage device for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as claimed in any one of claims 1-8 or the method as claimed in any one of claims 9-10.

14. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-8 or the method as described in any one of claims 9-10.

15. A computer program product comprising a computer program, characterized in that, When the program is executed, it implements the method as described in any one of claims 1-8 or the method as described in any one of claims 9-10.

Images