Data processing method, apparatus, device, and computer program based on blockchain
The proposed method addresses the issue of failed multi-party cooperative transactions in blockchain systems by ensuring all transactions within a group succeed or fail together, thereby enhancing the accuracy of transaction data in the blockchain.
Patent Information
- Application Number
- JP2023558388
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-08-06
- Filing Date
- 2022-06-17
- Publication Date
- 2025-06-18
- Estimated Expiration
- 2042-06-17
AI Technical Summary
In blockchain systems, multi-party cooperative transactions fail because individual transactions are independent, leading to successful transactions being written to the ledger despite execution failures in other transactions, reducing data accuracy.
A data processing method where a consensus node determines group transaction data with the same group identifier, packs them into a proposed block, executes them, and updates results to failure if any transaction fails, ensuring all transactions in a group succeed or fail together before being written to the blockchain.
This method ensures the accuracy of transaction data by guaranteeing that all transactions in a multi-party cooperative transaction either succeed or fail collectively, preventing partial successful transactions from being written to the blockchain.
Smart Images

Figure 0007694001000002 
Figure 0007694001000003 
Figure 0007694001000004
Abstract
Description
Technical Field
[0001] (Cross - Reference to Related Applications) This application claims the priority of a Chinese patent application with the application number 202110901263.X, filed with the Chinese Patent Office on August 6, 2021, and all of its content is incorporated herein by reference.
[0002] This application relates to the field of computer technology, and in particular, to a data processing method, apparatus, device, readable storage medium, and computer program product based on blockchain.
Background Art
[0003] Blockchain is a new application mode that integrates computer technologies such as distributed data storage, peer - to - peer transmission, consensus mechanism, and encryption algorithms. Blockchain is mainly used to sort data in time series, encrypt and ledger the data, prevent data tampering and forgery, and at the same time enable data verification, storage, and update. In addition, blockchain enables encrypted transmission of data, identification of nodes, and secure access, and is an advanced distributed infrastructure. Currently, due to the anti - tampering and authenticity of blockchain, the application of blockchain is increasing.
[0004] A transaction is the minimum required unit in a blockchain system. One transaction can be regarded as a single operation request to the blockchain service side, and this operation request allows the blockchain system to execute several transaction operations. However, only one individual or both are involved in one transaction. In scenarios of multi - party cooperation (also called "multi - party collaboration"), usually, multiple transactions are often generated, and these transactions should succeed or fail simultaneously, thereby guaranteeing the interests of all participants.
[0005] However, in the blockchain systems of related technologies, different transactions are mutually independent and isolated in the blockchain. For multiple transactions generated in a scenario of cooperation among multiple parties, if the execution of some transactions fails, the transactions that have been successfully executed are still written into the blockchain ledger, and the parties that have succeeded in the transaction do not start a new transaction for the parties that have failed in the transaction. Therefore, a complete multi-party cooperative transaction cannot be saved in the blockchain ledger. As a result, the multi-party cooperative transaction based on the blockchain fails, reducing the accuracy of the transaction data in the blockchain.
Summary of the Invention
[0006] Embodiments of the present application provide a data processing method, apparatus, device, readable storage medium, and computer program product based on a blockchain, which can improve the accuracy of the transaction data of the blockchain.
[0007] Embodiments of the present application provide a data processing method based on a blockchain, which is applied to a computer device. The computer device is mapped as a consensus node in a blockchain network, and the data processing method based on the blockchain includes: a step in which the consensus node determines a plurality of transaction data having the same group identifier in a transaction pool as group transaction data; a step of packing each of the group transaction data into a proposed block, executing each of the group transaction data in the proposed block, and obtaining an execution result of the executed transaction; If the executed transaction execution result includes a transaction execution failure result, update the transaction execution results corresponding to each of the group transaction data to transaction execution failure results, update the proposed block based on the transaction execution failure results corresponding to each of the group transaction data, and obtain a target proposed block; If the target proposed block is approved by consensus, perform a bookkeeping process on the target proposed block and the transaction execution failure results corresponding to each of the group transaction data.
[0008] The embodiments of the present application provide a blockchain-based data processing method applicable to a computer device. The computer device is mapped as a service node in a blockchain network, and the blockchain-based data processing method includes: Receiving a transaction request for a multi-party cooperative transaction sent from a terminal device by the service node; Determining a group identifier corresponding to the multi-party cooperative transaction based on the transaction request; Generating transaction data having a group identifier based on the group identifier corresponding to the multi-party cooperative transaction and the transaction request, and adding the transaction data to a transaction pool. The transaction pool has a plurality of transaction data with the same group identifier, and the transaction data is for being determined as group transaction data by a consensus node. The consensus node packs each of the group transaction data into a proposed block, executes each of the group transaction data in the proposed block, and is for obtaining an executed transaction execution result. The consensus node further, when the executed transaction execution result includes a transaction execution failure result, is for updating any transaction execution result corresponding to each of the group transaction data to a transaction execution failure result.
[0009] Embodiments of the present application provide a data processing device based on a blockchain. The data processing device based on the blockchain is a group determination module configured to determine a plurality of transaction data having the same group identifier in a transaction pool as group transaction data, a packing module configured to pack each of the group transaction data into a proposed block, a block execution module configured to pack each of the group transaction data into a proposed block, execute each of the group transaction data in the proposed block, and obtain an executed transaction execution result, a result update module configured to update any transaction execution result corresponding to each of the group transaction data to a transaction execution failure result when the executed transaction execution result includes a transaction execution failure result, a block update module configured to update the proposed block based on the transaction execution failure result corresponding to each of the group transaction data and obtain a target proposed block, When the target proposed block is approved by consensus, it includes a bookkeeping module configured to perform bookkeeping processing on the target proposed block and the transaction execution failure results corresponding to each of the group transaction data.
[0010] Embodiments of the present application provide a data processing device based on a blockchain. The data processing device based on the blockchain includes a request receiving module configured to receive a transaction request for a multi-party cooperative transaction transmitted from a terminal device, an identifier determination module configured to determine a group identifier corresponding to the multi-party cooperative transaction based on the transaction request, a data addition module configured to generate transaction data having a group identifier based on the group identifier corresponding to the multi-party cooperative transaction and the transaction request, and add the transaction data to a transaction pool. The transaction pool has a plurality of transaction data with the same group identifier. The transaction data is for being determined as group transaction data by a consensus node. The consensus node packs each of the group transaction data into a proposed block, executes each of the group transaction data in the proposed block, and obtains an executed transaction execution result. Further, when the executed transaction execution result includes a transaction execution failure result, the consensus node is for updating all the transaction execution results corresponding to each of the group transaction data to the transaction execution failure result.
[0011] Embodiments of the present application provide a computer device including a processor, a memory, and a network interface. The processor is connected to the memory and the network interface. The network interface is for providing a data communication function. The memory is for storing a computer program. The processor is for calling the computer program to execute the blockchain-based data processing method in the embodiments of the present application.
[0012] Embodiments of the present application provide a computer-readable storage medium storing a computer program. The computer program is loaded into a processor and is suitable for executing the blockchain-based data processing method in the embodiments of the present application.
[0013] Embodiments of the present application provide a computer program product or a computer program including computer instructions. The computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the blockchain-based data processing method in the embodiments of the present application on the computer device.
[0014] In the embodiments of the present application, group transaction data having the same group identifier can be packed into the same proposed block. Further, if the execution of one piece of group transaction data fails, it is determined that the execution of all group transaction data has failed. In this way, after a part of the group transaction data generated in a multi-party cooperative transaction fails to be executed, it can be prevented that a part of the group transaction data that has succeeded in the transaction is written to the blockchain. Therefore, according to the embodiments of the present application, it is ensured that the multi-party cooperative transaction based on the blockchain succeeds only when all group transaction data succeeds in execution, thereby improving the accuracy of the transaction data of the blockchain.
Brief Description of the Drawings
[0015]
Figure 1
Figure 2a
Figure 2b
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Embodiments for Carrying Out the Invention
[0016] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of them. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative efforts are included in the protection scope of the present application.
[0017] It should be noted that the transaction related to the embodiment of the present application is also called a transaction request. A transaction includes an operation that needs to be submitted to and executed in the blockchain network and the corresponding transaction result. The transaction related to the embodiment of the present application is not limited to the transaction in the business environment, that is, the transaction data is not limited to related data such as digital currency. For example, the transaction can be a deploy transaction or an invoke transaction. The deploy transaction is used to deploy a smart contract to the nodes of the blockchain network to prepare for being invoked. The invoke transaction is used to perform a query operation (i.e., a read operation) or an update operation (i.e., a write operation, including increment, deletion, and modification) on the state database in the ledger.
[0018] Referring to FIG. 1, FIG. 1 is a schematic diagram of an example of the network architecture provided by an embodiment of the present application. The blockchain is a new application mode that integrates computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. The blockchain is mainly used to sort data in chronological order, encrypt and ledger the data, prevent data tampering and forgery, and at the same time enable data verification, storage, and update. Essentially, the blockchain is a decentralized (distributed) database, and each node in the database stores the same blockchain. Nodes in the blockchain network include consensus nodes (for example, consensus node 1000a shown in FIG. 1) and service nodes (for example, service node 100a shown in FIG. 1). The consensus node is for the consensus of the entire blockchain network, and the service node is for processing transaction requests sent from terminal devices (where the client is executed). The process of writing transaction data into the ledger in the blockchain network can include the client sending transaction data to the service node, the transaction data being relayed between service nodes in the blockchain network until the consensus node receives the transaction data, the consensus node packing the transaction data into a block and seeking consensus with other consensus nodes, and after reaching consensus, writing the block carrying the transaction data into the ledger.
[0019] Here, it is understandable that a block is a data package that carries transaction data (i.e., transaction services) in the blockchain network, and is a data structure marked with a timestamp and the hash value of the previous block. The block is verified by the consensus mechanism of the network, thereby determining the transactions in the block.
[0020] Here, it is understandable that the hash value is also called the information feature value or the feature value. The hash value is generated by converting input data of any length into a password and fixedly outputting it by means of a hash algorithm. The original input data cannot be retrieved by decrypting the hash value, and the hash algorithm is a one-way encryption function. In a blockchain, each block (except the initial block) contains the hash value of the previous block, and the previous block is called the parent block of the current block. The hash value is the core foundation and the most important part in blockchain technology, and can guarantee the authenticity of the recorded data and the viewed data, as well as the integrity of the blockchain as a whole.
[0021] Here, it is understandable that the blockchain system can include smart contracts, and the smart contracts can be understood as code that each node (including consensus nodes) in the blockchain system can understand and execute, and can execute any logic and obtain results. Users can call the deployed smart contracts in the blockchain by the way that the client initiates a transaction service request. Next, the service nodes in the blockchain can send the transaction service request to the consensus nodes, and each consensus node in the blockchain can execute the smart contract respectively. It is understandable that the blockchain can include one or more smart contracts, and these smart contracts can be distinguished by identifier numbers (ID: Identity document) or names. The transaction service request initiated by the client can also carry the identifier number or name of the smart contract, thereby specifying the smart contract that the blockchain needs to execute. If the smart contract specified by the client is a contract that needs to read data, each consensus node accesses the local ledger and reads the data. Finally, each consensus node mutually verifies whether the execution results match (i.e., conducts consensus). If they match, the execution results are stored in their respective local ledgers, and the execution results can be returned to the client.
[0022] As shown in FIG. 1, the network architecture can include a consensus node cluster 1000, a service node cluster 100, and a terminal device (where a client is executed) cluster 10. The consensus node cluster 1000 can include at least two consensus nodes, and the service node cluster 100 can include at least two service nodes. As shown in FIG. 1, the consensus node cluster 1000 can include a consensus node 1000a, a consensus node 1000b, …, a consensus node 1000n. Specifically, the service node cluster 100 can include a service node 100a, a service node 100b, …, a service node 100n. Specifically, the terminal device cluster 10 can include a terminal device 10a, a terminal device 10b, …, a terminal device 10n.
[0023] As shown in FIG. 1, each of the terminal devices 10a, 10b, …, 10n can establish a network connection with the service nodes 100a, 100b, …, 100n. Thereby, the terminal devices can perform data interaction with the service nodes through the network connection. Each of the service nodes 100a, 100b, …, 100n can establish a network connection with the consensus nodes 1000a, 1000b, …, 1000n. Thereby, the service nodes can perform data interaction with the consensus nodes through the network connection. The service nodes 100a, 100b, …, 100n are interconnected with each other. Thereby, data interaction can be performed among the service nodes. The consensus nodes 1000a, 1000b, …, 1000n are interconnected with each other. Thereby, data interaction can be performed among the consensus nodes.
[0024] As is possible to understand, data or block transmission can be performed between blockchain nodes (which can be the above service nodes or consensus nodes) through the above data connection. The blockchain network can realize the data connection between blockchain nodes based on node identifiers. Each blockchain node in the blockchain network has a corresponding node identifier. Furthermore, each of the above blockchain nodes can store the node identifiers of other blockchain nodes that have a connection relationship with itself, so that subsequently, based on the node identifiers of other blockchain nodes, the acquired data or the generated block can be broadcast to other blockchain nodes. For example, in service node 100a, a node identifier list shown in Table 1 can be held, and the node identifier list stores the node names and node identifiers of other blockchain nodes.
[0025]
Table 1
[0026] Understandably, the above data connection is not limited to the connection method and can be directly or indirectly connected by a wired communication method, can also be directly or indirectly connected by a wireless communication method, and can even be connected by other connection methods. The present application does not limit this aspect.
[0027] Understandably, the blockchain-based data processing method provided in the embodiments of the present application can be executed by a computer device. The computer device includes, but is not limited to, the above consensus node or service node (which can be a terminal or a server). The above server can be an independent physical server, can also be a server cluster or distributed system composed of multiple physical servers, or can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, big data, and artificial intelligence platforms. The above terminal can be, but is not limited to, a smartphone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, an in-vehicle terminal, etc.
[0028] As shown in FIG. 1, any consensus node in the consensus node cluster 1000 can function as a block producer node, obtain a plurality of transaction data having the same group identifier from the transaction pool, and determine each group of transaction data as transaction data. Here, the transaction pool is a temporary list that each blockchain node in the blockchain network needs to hold for storing transaction data. The blockchain node temporarily stores transaction data that is known in the blockchain network but not yet included in the blockchain by the transaction pool. Next, the block producer node packs each group of transaction data into a proposed block (a block that stores the group transaction data in the blockchain), sequentially executes each group of transaction data in the proposed block, and can obtain the executed transaction execution result. If the executed transaction execution result includes a transaction execution failure result, all the transaction execution results corresponding to each group of transaction data are updated to the transaction execution failure result, and the proposed block is updated based on the transaction execution failure result corresponding to each group of transaction data to obtain a target proposed block. Next, when the target proposed block is approved by consensus, accounting processing is performed on the target proposed block and the transaction execution failure result corresponding to each group of transaction data. Here, the process of updating the proposed block based on the transaction execution failure result corresponding to each group of transaction data to obtain the target proposed block may be as follows. A result Merkle tree is generated based on the transaction execution failure result corresponding to each group of transaction data, and the tree root hash value of the result Merkle tree is added to the block header of the proposed block to obtain the target proposed block. Here, the accounting processing is to write and store the target proposed block and the transaction execution failure result corresponding to each group of transaction data in the blockchain ledger.If the execution result of the executed transaction does not include the transaction execution failure result, directly generate a result Merkle tree based on the execution result of the executed transaction, add the tree root hash value of the result Merkle tree to the proposed block to obtain an updated proposed block, and perform bookkeeping processing on the updated proposed block and the execution result of the executed transaction.
[0029] The transaction data in the above transaction pool can be sent from any service node in the service node cluster 100. As shown in FIG. 1, any service node in the service node cluster 100 can receive a transaction request for a multi-party cooperative transaction sent from a terminal device in the terminal device cluster 10, where the number of transaction requests is plural. When the number of transaction requests is plural, they may be sent from the same terminal device or from different terminal devices, and this is not limited herein. Here, a multi-party cooperative transaction is a scenario where multiple participants conduct a transaction together. In this scenario, usually one or more transactions are generated, and these transactions should succeed in execution simultaneously and be written into the blockchain ledger together. Next, any service node in the service node cluster 100 can determine a group identifier corresponding to the multi-party cooperative transaction based on the transaction request, generate transaction data having the group identifier based on the group identifier corresponding to the multi-party cooperative transaction and the transaction request, add the transaction data having the group identifier to the transaction pool, and wait for the processing of the above block producer node. For example, a terminal device in the terminal device cluster 10 can directly obtain a group identifier corresponding to a multi-party cooperative transaction, generate a transaction request for the multi-party cooperative transaction based on the group identifier, and send the transaction request carrying the group identifier to any service node in the service node cluster 100. After receiving the transaction request carrying the group identifier, the service node can directly generate transaction data having the group identifier and add the transaction data carrying the group identifier to the transaction pool.
[0030] For ease of understanding, referring to FIGS. 2a to 2b, FIGS. 2a to 2b are schematic diagrams of an example of a scenario of blockchain-based data processing provided in an embodiment of the present application. Here, the terminal device 20a corresponding to user A, the terminal device 20b corresponding to user B, and the terminal device 20c corresponding to user C shown in FIG. 2a can all be any terminal device in the terminal device cluster 10 in FIG. 1 above. For example, the terminal device 20a can be the terminal device 10a, the terminal device 20b can be the terminal device 10b, and the terminal device 20c can be the terminal device 10n. The service node 200 shown in FIG. 2a can be any service node in the service node cluster 100 in FIG. 1 above. For example, the service node can be the service node 100b. The consensus node 201 shown in FIG. 2b can be any service node in the consensus node cluster 1000 in FIG. 1 above. For example, the consensus node can be the consensus node 1000a.
[0031] As shown in FIG. 2a, user A, user B, user C, and user D (not shown) are participating in a multi-party collaborative transaction f. According to the agreement among the four people, user A needs to transfer 100 yuan to user B, user B needs to transfer 60 yuan to user C, and user C needs to transfer 30 yuan to user D. Therefore, user A starts a transaction request 1 for "user A transfers 100 yuan to user B" on terminal device 20a, user B starts a transaction request 2 for "user B transfers 60 yuan to user C" on terminal device 20b, and user C starts a transaction request 3 for "user C transfers 30 yuan to user D" on terminal device 20c. Understandably, if the execution of transaction request 2 fails and the executions of transaction request 1 and transaction request 3 succeed, that is, user A successfully transfers to user B, user C successfully transfers to user D, but user B does not successfully transfer to user C, then user B has received 60 yuan more. At this time, if user B refuses to return the transfer from user A and also refuses to transfer 60 yuan to user C again, the interests of both user A and user C may be damaged, and the success of the multi-party collaborative transaction based on the blockchain and the accuracy of the transaction data of the blockchain cannot be guaranteed. In the embodiment of the present application, a plurality of transactions generated in the multi-party collaborative transaction are regarded as group transactions of the same group. If the execution of any one of the group transactions in the same group fails, it is considered that the executions of all group transactions have failed. Therefore, the success of the multi-party collaborative transaction based on the blockchain is guaranteed, and the accuracy of the transaction data of the blockchain is improved.
[0032] As shown in FIG. 2a, User A, User B, and User C are performing a federated learning task for the product recommendation model. User A has the first part of the training data for the product recommendation model, User B has the second part of the training data for the product recommendation model, and User C has the third part of the training data for the product recommendation model. Here, the first part of the training data, the second part of the training data, and the third part of the training data constitute the complete training data for training the product recommendation model. Therefore, User A starts transaction request 1 for "training the product recommendation model with the first part of the training data" on terminal device 20a, User B starts transaction request 2 for "training the product recommendation model with the second part of the training data" on terminal device 20b, and User C starts transaction request 3 for "training the product recommendation model with the third part of the training data" on terminal device 20c. Understandably, if the execution of transaction request 2 fails and the executions of transaction request 1 and transaction request 3 succeed, that is, the training of the product recommendation model with the first part of the training data is successful and the training of the product recommendation model with the third part of the training data is successful, but the training of the product recommendation model with the second part of the training data fails, the product recommendation model fails to be trained because the training of the second part of the training data is lacking. Even if the transaction data for training the product recommendation model with the first part of the training data and the transaction data for training the product recommendation model with the third part of the training data are stored, the success of the multi-party cooperative transaction based on the blockchain, that is, the success of the product recommendation model, cannot be guaranteed. Only when the execution of all transactions is successful can the success of the multi-party cooperative transaction based on the blockchain be guaranteed. In this way, the accuracy of the transaction data on the blockchain is improved. Furthermore, based on the characteristics of data privacy protection in federated learning, the training model is independently trained with each training data, so as to improve the security of the transaction data on the blockchain.
[0033] As shown in Fig. 2a, User A, User B, and User C are performing a collaborative development task on the target code. User A needs to develop the first part of the target code, User B needs to develop the second part of the target code, and User C needs to develop the third part of the target code. Here, the first part of the code, the second part of the code, and the third part of the code constitute the complete target code. Therefore, User A starts transaction request 1 for the "development task for the first part of the code" on terminal device 20a, User B starts transaction request 2 for the "development task for the second part of the code" on terminal device 20b, and User C starts transaction request 3 for the "development task for the third part of the code" on terminal device 20c. Understandably, if the execution of transaction request 2 fails and the execution of transaction request 1 and transaction request 3 succeed, that is, the development of the first part of the code is successful, the development of the third part of the code is successful, but the development fails due to the second part of the code, at this time, because the second part of the code is missing, the development of the target code fails, and the success of the multi-party collaborative transaction based on the blockchain cannot be guaranteed. Only when the execution of all transactions is successful can the success of the multi-party collaborative transaction based on the blockchain be guaranteed. In this way, the accuracy and completeness of the transaction data of the blockchain are improved, and furthermore, through multi-party code collaborative development, the development efficiency of the transaction data (i.e., the developed code) of the blockchain is improved.
[0034] As shown in FIG. 2a, after receiving transaction request 1, transaction request 2, and transaction request 3, service node 200 determines a group identifier corresponding to the multi-party cooperative transaction f and assumes it as group identifier F. Next, the service node generates transaction data having the group identifier based on the group identifier corresponding to the multi-party cooperative transaction and the transaction request. That is, as shown in FIG. 2a, service node 200 generates transaction data 1 based on transaction request 1 and group identifier F, service node 200 generates transaction data 2 based on transaction request 2 and group identifier F, and service node 200 generates transaction data 3 based on transaction request 3 and group identifier F. Transaction data 1, transaction data 2, and transaction data 3 all carry group identifier F. Next, service node 200 adds transaction data 1, transaction data 2, and transaction data 3 to transaction pool 202. As can be seen from the above, transaction pool 202 is a temporary list that stores transaction data, which each blockchain node in the blockchain node holds.
[0035] For example, after transaction data with a group identifier enters the transaction pool, it waits to be packed into a proposed block by a block producer node. Assuming that the block producer node is the consensus node 201, the consensus node 201 can extract the transaction data from the transaction pool 202, pack it into the proposed block, and broadcast it to the blockchain network to perform the consensus accounting process. As shown in FIG. 2b, the consensus node 201 determines the transaction data 1, transaction data 2, and transaction data 3 with the group identifier F from the transaction pool as the group transaction data of the same group 2011, and then packs each group transaction data in the group 2011 into the proposed block 2015. Here, the proposed block includes a block header and a block body. The block header stores basic data such as a version number, a timestamp, and a difficulty value, and can further store other related data. The block body is for storing each group transaction data in the group 2011. Understandably, the proposed block can store group transaction data corresponding to multiple groups. If one of the transaction execution results corresponding to the group transaction data corresponding to the same group is a transaction execution failure result, the transaction execution results corresponding to all the group transaction data in the group are updated to the transaction execution failure result. The transaction execution results corresponding to the group transaction data corresponding to different groups do not affect each other. Assuming that the proposed block has group transaction data corresponding to group A and group B respectively, if the execution of the group transaction data a in group A fails, the transaction execution results corresponding to the group transaction data in group B are not affected.
[0036] As shown in FIG. 2b, the consensus node 201 sequentially executes each group transaction data in the proposed block, that is, sequentially executes group transaction data 2012, group transaction data 2013, and group transaction data 2014, and obtains the executed transaction execution results. Assuming that the transaction execution result 2016 corresponding to the group transaction data 2012 is a successful transaction execution result, the transaction execution result 2017 corresponding to the group transaction data 2013 is a successful transaction execution result, and the transaction execution result 2018 corresponding to the group transaction data 2014 is a failed transaction execution result, that is, when the executed transaction execution results include a failed transaction execution result, the consensus node 201 updates the transaction execution results, that is, updates the transaction execution results corresponding to each group transaction data to the failed transaction execution results. After the update is performed, the transaction execution result 2016 corresponding to the group transaction data 2012 is a failed transaction execution result, the transaction execution result 2017 corresponding to the group transaction data 2013 is a failed transaction execution result, and the transaction execution result 2018 corresponding to the group transaction data 2014 is a failed transaction execution result. The consensus node 201 updates the proposed block based on the failed transaction execution results corresponding to each group transaction data, obtains the target proposed block, and then performs a consensus accounting process on the target proposed block, that is, after the consensus of the consensus node cluster in the blockchain (which may be the consensus node cluster 1000 shown in FIG. 1 above) is approved, the consensus node 201 can perform an accounting process on the target proposed block and the failed transaction execution results corresponding to each group transaction data.
[0037] Referring to FIG. 3, FIG. 3 is a flowchart of an example of a blockchain-based data processing method provided by an embodiment of the present application. Here, the method may be executed on a consensus node (for example, the consensus node in FIG. 1 above), or may be jointly executed on a service node, a consensus node (for example, the consensus node in the embodiment corresponding to FIG. 1 above), and a terminal device (for example, the terminal device in the embodiment corresponding to FIG. 1 above). In the following, an example will be given to illustrate that the method is executed on a consensus node. Here, the blockchain-based data processing method may include at least the following steps S101 to S104.
[0038] In step S101, the consensus node determines a plurality of transaction data having the same group identifier in the transaction pool as group transaction data.
[0039] For example, the group identifier is for identifying the transaction group to which the transaction data belongs. In other words, the transaction data included in the same transaction group has the same group identifier. Understandably, the group identifier has uniqueness, that is, the group identifiers corresponding to different transaction groups are different, and the group identifiers corresponding to the transaction data belonging to different transaction groups are different. In the blockchain system of the related art, transactions in the blockchain are isolated from each other independently, and the success or failure of the execution of one transaction does not affect other transactions. For the transaction group of the embodiment of the present application, a plurality of transactions having a related relationship in the blockchain are added to the same transaction group, and the transaction group has the characteristic that all transactions in the transaction group are successfully executed or all are failed in execution.
[0040] For example, after generating transaction data, the service node adds the transaction data to the transaction pool. Next, the consensus node with the block producer function (i.e., the block producer node) waits for taking out the transaction data from the transaction pool and packing it into the proposed block. The transaction data corresponding to the transactions added to the same transaction group carries a group identifier, and the consensus node determines multiple pieces of transaction data with the same group identifier in the transaction pool as group transaction data.
[0041] In some embodiments, the process by which the consensus node determines the group transaction data may be as follows. The consensus node can obtain the transaction data from the transaction pool. Here, the transaction data includes a group identifier and the group transaction quantity. The group transaction quantity is the quantity of transactions included in the transaction group corresponding to the group identifier. Next, the consensus node adds the transaction data to the group cache queue corresponding to the group identifier and can obtain an updated group cache queue. When the quantity of the transaction data in the updated group cache queue is equal to the group transaction quantity, the transaction data in the updated group cache queue is determined as the group transaction data. When the quantity of the transaction data in the updated group cache queue is smaller than the group transaction quantity, the consensus node continues to obtain the transaction data including the group identifier from the transaction pool.
[0042] Here, the group cache queue is for temporarily storing transaction data corresponding to a part of the transactions in the transaction group that the consensus node has already obtained. The group cache queue corresponding to the group identifier is established after the consensus node obtains the first transaction data carrying the group identifier. When all the transaction data in the group cache queue are packed into the blockchain, the transaction data in the group cache queue are cleared, and the resources occupied by the group cache queue are released, that is, the consensus node deletes the group cache queue.
[0043] To make it easier to understand, assume that the consensus node has obtained transaction data A. Transaction data A includes a group identifier m and the group transaction quantity, where the group transaction quantity is 3. Next, the consensus node adds transaction data A to the group cache queue corresponding to the group identifier m and obtains an updated cache queue. It should be noted that if the consensus node does not query the group cache queue corresponding to the group identifier m, the consensus node establishes the group cache queue corresponding to the group identifier m and adds transaction data A to the group cache queue. For example, the size of the group cache queue can be dynamically adjusted based on the group transaction quantity to avoid occupying too many memory resources. Next, the consensus node determines the quantity of transaction data in the updated cache queue. Assume that the group cache queue contains previously added transaction data B. At this time, the quantity of transaction data in the updated cache queue is 2, which is less than the group transaction quantity. The consensus node continues to obtain new transaction data from the transaction pool, determines the group identifier corresponding to the new transaction data, adds the new transaction data to the group cache queue corresponding to the group identifier m, and then repeats the above process. The consensus node adds the transaction data C to the updated group cache queue and obtains a new updated group cache queue until the group identifier corresponding to the newly obtained transaction data C by the consensus node is the group identifier m. At this time, the new updated group cache queue includes transaction data A, transaction data B, and transaction data C, and the quantity of transaction data is 3, which is equal to the group transaction quantity.In this case, the consensus node determines the transaction data A, transaction data B, and transaction data C as group transaction data corresponding to the same transaction group.
[0044] In some embodiments, when the quantity of transaction data in the update group cache queue is smaller than the target group transaction quantity, the process of continuously obtaining transaction data including the target group identifier from the transaction pool may be as follows. When the quantity of transaction data in the update group cache queue is smaller than the group transaction quantity and the current time is within the cache time range, continuously obtain transaction data including the group identifier from the transaction pool. When the quantity of transaction data in the update group cache queue is smaller than the group transaction quantity and the current time exceeds the cache time range, re-enter the transaction data in the update group cache queue into the transaction pool and clear the update group cache queue.
[0045] It should be noted that the group identifiers of different transaction groups correspond to different group cache queues. If the consensus node fails to obtain all the transaction data belonging to the same transaction group for a long time, the group cache queue will occupy the memory resources of the consensus node all the time and waste a large amount of memory resources. Therefore, a cache time range, that is, the longest possible time range since a group cache queue was established, can be set. When the existence time of the group cache queue exceeds the cache time range, re-enter the transaction data in the group cache queue into the transaction pool, clear the group cache queue, and avoid the group cache queue occupying the memory resources of the consensus node, thereby saving memory resources.
[0046] In step S102, each group transaction data is packed into a proposal block, each group transaction data in the proposal block is executed, and an executed transaction execution result is obtained.
[0047] In some embodiments, the group transaction data can include an execution order identifier, and the execution order identifier is the execution order of transactions in a transaction group. The process of packing each group transaction data into a proposal block can be as follows. Based on the execution order identifier included in each group transaction data, a sorting process is executed on each group transaction data to obtain the sorted group transaction data, and then the sorted group transaction data is packed into a proposal block. Thereafter, the consensus node executes each group transaction data in the proposal block in sequence according to the packing order of the group transaction data to obtain an executed transaction execution result.
[0048] It should be noted that in the embodiments of the present application, each group transaction data in the proposal block can be executed according to the packing order of the group transaction data. Of course, in the embodiments of the present application, further, each group transaction data in the proposal block can be executed randomly.
[0049] In some embodiments, assuming that the quantity of group transaction data is S, and S is a positive integer greater than 1, the process of executing each group transaction data in the proposal block and obtaining the executed transaction execution result may be as follows. Obtain the k-th group transaction data in the proposal block, execute the k-th group transaction data, and obtain the transaction execution result corresponding to the k-th group transaction data. Here, k is a positive integer that increases sequentially, and k is smaller than S. If the transaction execution result corresponding to the k-th group transaction data is a successful transaction execution result, continue to execute the (k + 1)-th group transaction data in the proposal block. If the transaction execution result corresponding to the k-th group transaction data is a failed transaction execution result, determine that the transaction execution results corresponding to each of the (k + 1)-th group transaction data to the S-th group transaction data in the proposal block are all failed transaction execution results. The transaction execution result corresponding to each group transaction data is used as the executed transaction execution result.
[0050] Simply put, in order to improve the operating efficiency of the blockchain system, when the consensus node sequentially executes each group transaction data in the proposed block, if the transaction execution result of one group transaction data is a transaction execution failure result, the transaction execution results of other group transaction data after that group transaction data are directly determined as transaction execution failure results without the need for further calculation, thereby saving computing resources. For example, following the packing order, the proposed block includes group transaction data a, group transaction data b, group transaction data c, and group transaction data d. When the consensus node executes the proposed block, it first executes group transaction data a. Assuming that the transaction execution result corresponding to group transaction data a is a transaction execution success result, it then continues to execute group transaction data b. Assuming that the transaction execution result corresponding to group transaction data b is a transaction execution failure result, the consensus node does not need to execute group transaction data c and group transaction data d, and can directly determine the transaction execution results corresponding to group transaction data c and group transaction data d as transaction execution failure results. At this time, the executed transaction execution results are the transaction execution success result corresponding to group transaction data a, the transaction execution failure result corresponding to group transaction data b, the transaction execution failure result corresponding to group transaction data c, and the transaction execution failure result corresponding to group transaction data d.
[0051] In some embodiments, the process of executing the k-th group transaction data may be as follows. Call the transaction execution function in the smart contract for executing the group transaction data, obtain the historical transaction data for the k-th group transaction data based on the transaction execution function, and determine the historical transaction data as the read data. Next, execute the transaction execution function based on the read data and the group transaction data to obtain the transaction execution result of the group transaction data. For example, the group transaction data corresponding to the k-th transaction is that Party A transfers 10 yuan to Party B through its own account. The transaction execution function k corresponding to the k-th group transaction data is a transfer execution function, and the historical transaction data k corresponding to the k-th group transaction data is that the balance of Party A's account is 20 yuan. The transaction execution result k for the k-th group transaction data may be 20 - 10 = 10 yuan, that is, after executing transaction k, the balance of Party A's account is 10 yuan.
[0052] In step S103, if the transaction execution failure result is included in the executed transaction execution result, update the transaction execution result corresponding to each group transaction data to the transaction execution failure result, update the proposed block based on the transaction execution failure result corresponding to each group transaction data, and obtain the target proposed block.
[0053] For example, transactions belonging to the same transaction group should succeed or fail simultaneously. Therefore, only when the executed transaction execution result does not include a transaction execution failure result, the consensus node updates the proposed block based on the executed transaction execution result. When the executed transaction execution result includes one or more transaction execution failure results, the consensus node updates the transaction execution result corresponding to each group transaction data to a transaction execution failure result, and then updates the proposed block based on the transaction execution failure result corresponding to each group transaction data to obtain a target proposed block. For example, the executed transaction execution result obtained in step S102 above is a transaction execution success result corresponding to group transaction data a, a transaction execution failure result corresponding to group transaction data b, a transaction execution failure result corresponding to group transaction data c, and a transaction execution failure result corresponding to group transaction data d. At this time, the consensus node updates the transaction execution success result corresponding to group transaction data a to a transaction execution failure result. At this time, the transaction execution result corresponding to each group transaction data is a transaction execution failure result.
[0054] In some embodiments, the step of updating the proposed block based on the transaction execution failure result corresponding to each group transaction data to obtain a target proposed block includes the step of generating a result Merkle tree based on the transaction execution failure result corresponding to each group transaction data, where the result Merkle tree includes a tree root hash value, and the step of adding the tree root hash value to the block header of the proposed block to obtain a target proposed block.
[0055] It should be noted that the result Merkle tree is a type of Merkle tree (also called a hash tree), and the Merkle tree is a type of data structure, that is, a binary tree. The Merkle tree is composed of a root, branches (intermediate non-leaf nodes), and leaf nodes. What is stored in all nodes is the hash value of the relevant data (not the relevant data itself). For example, what is stored in the root node is the tree root hash value, not the data of the tree root itself.
[0056] In step S104, when the target proposed block is approved by consensus, accounting processing is performed on the target proposed block and the transaction execution failure results corresponding to each group transaction data.
[0057] For example, the accounting processing is to add the group transaction data in the target proposed block and the transaction execution failure results corresponding to each group transaction data to the blockchain ledger for storage.
[0058] In some embodiments, the consensus node can broadcast the proposed block to the communicable consensus nodes in the consensus network. The communicable consensus nodes can execute each group transaction data in the proposed block, update the proposed block based on the transaction execution result corresponding to each group transaction data, and obtain a communicable target proposed block. The consensus node can receive the block hash value of the communicable target proposed block sent from the communicable consensus node, and at the same time, can broadcast the block hash value of the target proposed block to the communicable consensus nodes in the consensus network. The consensus node determines the block hash value of the communicable target proposed block as the matching target block hash value, and then compares the matching target block hash value with the block hash value of the target proposed block. If the quantity of the matching target block hash values that are the same as the block hash value of the target proposed block is greater than the consensus quantity threshold, it is determined that the target proposed block has been approved by consensus.
[0059] In the method provided by the embodiments of the present application, a plurality of transaction data having the same group identifier in a transaction pool are determined as group transaction data. Next, each group transaction data is packed into a proposal block, each group transaction data in the proposal block is executed, and an executed transaction execution result can be obtained. If the executed transaction execution result includes a transaction execution failure result, all the transaction execution results corresponding to each group transaction data are updated to the transaction execution failure result, and the proposal block is updated based on the transaction execution failure result corresponding to each group transaction data to obtain a target proposal block. When the target proposal block is approved by consensus, accounting processing is performed on the target proposal block and the transaction execution failure result corresponding to each group transaction data. By using the transaction data having the same group identifier as the group transaction data, the transaction execution results of each group transaction data are bound, thereby ensuring that all the transactions generated in the multi-party cooperative transaction either succeed in execution or all fail in execution. In this way, after a part of the group transaction data generated in the multi-party cooperative transaction fails in execution, it is possible to avoid writing the part that has succeeded in the transaction in the group transaction data to the blockchain. Therefore, it is guaranteed that the multi-party cooperative transaction based on the blockchain succeeds only when all the group transaction data succeed in execution, thereby improving the accuracy of the transaction data in the blockchain.
[0060] Referring to FIG. 4, FIG. 4 is a flowchart of an example of a blockchain-based data processing method provided by an embodiment of the present application. Here, the method may be executed by a service node (for example, the service node in the embodiment corresponding to FIG. 1 above), or may be jointly executed by a service node, a consensus node (for example, the consensus node in the embodiment corresponding to FIG. 1 above), and a terminal device (for example, the terminal device in the embodiment corresponding to FIG. 1 above). In the following, an example will be described in which the method is executed by a service node. Here, the blockchain-based data processing method may include at least the following steps S201 to S203.
[0061] In step S201, the service node receives a transaction request for a multi-party cooperation transaction sent from a terminal device.
[0062] In some embodiments, a multi-party cooperation transaction is a transaction jointly participated in and executed by multiple participants, and the multi-party cooperation transaction generates a plurality of transaction requests. These transaction requests may be initiated by the same terminal device or by different terminal devices. It should be noted that the transaction requests generated by the multi-party cooperation transaction may also be sent to different service nodes. For the sake of easy understanding, in the subsequent steps, only the example where the transaction requests are sent to the same service node will be described.
[0063] In step S202, a group identifier corresponding to the multi-party cooperation transaction is determined based on the transaction request.
[0064] In some embodiments, when the quantity of the transaction requests is plural and each of the transaction requests includes an execution order identifier, the process of determining a group identifier corresponding to a multi-party cooperative transaction based on the transaction requests may be as follows. When obtaining a transaction request with the highest priority order indicated by the execution order identifier, the transaction request with the highest priority order is determined as a group identifier request. Next, a hash process is performed on the group identifier request to obtain a request hash value, and the request hash value is determined as the group identifier corresponding to the multi-party cooperative transaction.
[0065] For example, the execution order identifier is for indicating the order when the transaction request is executed, and the transaction request with the highest priority is the first transaction request to be executed indicated by the execution order identifier.
[0066] In some embodiments, when the transaction request includes a cooperative transaction start object that starts a multi-party cooperative transaction, the process of determining a group identifier corresponding to the multi-party cooperative transaction based on the transaction request may further be as follows. Obtain the cooperative transaction start object from the transaction request, search for an identifier corresponding to the cooperative transaction start object in the identifier library, and generate a group identifier corresponding to the multi-party cooperative transaction based on the identifier.
[0067] Here, the cooperative transaction start object can be the target of a multi-party cooperative transaction, for example, Party A when signing a contract in a two-party transaction. Here, the identifier library is for storing the identifiers of each transaction object (i.e., the target of a multi-party cooperative transaction). The identifier of a transaction object can be the identifier distributed by the service node after the transaction object starts an identifier acquisition request to the service node before starting a transaction request. Here, a transaction object is an object that can start a transaction request, and any transaction object can, as a cooperative transaction start object, induce other transaction objects to participate in a multi-party cooperative transaction. An identifier has uniqueness, that is, one transaction object corresponds to one identifier, and the identifiers corresponding to different transaction objects are different. Here, the process of generating a group identifier corresponding to a multi-party cooperative transaction based on the identifier can be as follows. The service node acquires the current timestamp, adds the current timestamp after the identifier, obtains a single unique identifier, and can use this identifier as the group identifier corresponding to the multi-party cooperative transaction.
[0068] In some embodiments, before starting a transaction request for a multi-party cooperative transaction, the terminal device can first apply for a corresponding group identifier for the multi-party cooperative transaction. When starting a transaction request for a multi-party cooperative transaction, the terminal device can directly carry the applied group identifier. The specific implementation process of applying for a group identifier can be as follows. The service node obtains an identifier acquisition request for a multi-party cooperative transaction started by the cooperative transaction start object, and the identifier acquisition request includes transaction objects participating in the multi-party cooperative transaction. Next, the service node can generate an available group identifier for the multi-party cooperative transaction based on the identifier acquisition request and send the available group identifier to the terminal device corresponding to the transaction object, whereby the terminal device corresponding to the transaction object generates a transaction request including the available group identifier. At this time, the process of determining the group identifier corresponding to the multi-party cooperative transaction based on the transaction request can be as follows. Determine the available group identifier in the transaction request as the group identifier corresponding to the multi-party cooperative transaction.
[0069] For example, the terminal device can further directly send a group identifier application request (i.e., an identifier acquisition request) to the service node, then receive the two-dimensional barcode image sent from the service node, obtain the group identifier by scanning the two-dimensional barcode image, and then generate a transaction request including the available group identifier based on the group identifier.
[0070] For example, before determining a group identifier corresponding to a multi-party cooperative transaction, first, the validity of the transaction request can be verified. Usually, the transaction request carries signature data, which is obtained after the terminal device signs the transaction request with a private key. The service node obtains the public key corresponding to the terminal device, performs a signature verification process on the signature data with the public key, and obtains a signature verification result. If the signature verification result is a signature verification success result, it is determined that the transaction request is valid, and the group identifier corresponding to the multi-party cooperative transaction is subsequently determined.
[0071] In step S203, transaction data having a group identifier is generated based on the group identifier corresponding to the multi-party cooperative transaction and the transaction request, and the transaction data is added to the transaction pool.
[0072] In some embodiments, a plurality of transaction data having the same group identifier in the transaction pool is determined as group transaction data by the consensus node. The consensus node packs each group transaction data into a proposal block, sequentially executes each group transaction data in the proposal block, and obtains an executed transaction execution result. If the executed transaction execution result includes a transaction execution failure result, the consensus node updates all the transaction execution results corresponding to each group transaction data to the transaction execution failure result.
[0073] Applying the method provided in the embodiments of the present application, a unique group identifier for a multi-party cooperative transaction can be generated. Transaction data generated based on transaction requests generated during the multi-party cooperative transaction process all carry the group identifier and are put into a transaction pool. Multiple transaction data with the same group identifier in the transaction pool are determined as group transaction data by a consensus node. There is a correlation between the transaction execution results of each group transaction data. If the transaction execution result of one group transaction data is a transaction execution failure result, the transaction execution results of other group transaction data are updated to transaction execution failure results, thereby ensuring that all transactions generated in the multi-party cooperative transaction either succeed or fail in execution. In this way, after a part of the group transaction data generated in the multi-party cooperative transaction fails in execution, it is possible to avoid writing the part that has succeeded in the transaction in the group transaction data to the blockchain. Therefore, it is guaranteed that the multi-party cooperative transaction based on the blockchain succeeds only when all group transaction data succeed in execution, thereby improving the accuracy of the transaction data of the blockchain.
[0074] Regarding the above process, reference may also be made to FIG. 5. FIG. 5 is a flowchart of an example of a method for executing group transaction data provided in the embodiments of the present application. The method can be executed on any node in the blockchain network (which can be the service node shown in FIG. 1 above or the consensus node shown in FIG. 1 above).
[0075] As shown in FIG. 5, the method for executing group transaction data can include the following steps S1 to S5.
[0076] In step S1, the Remote Procedure Call (RPC) layer at each node obtains a transaction request.
[0077] In some embodiments, the transaction request can carry a group identifier and can also carry basic information of a multi-party cooperative transaction, thereby facilitating a node to obtain the group identifier for the transaction request.
[0078] In step S2, each node broadcasts a transaction to each other, and one of them packs a plurality of transactions into one block as a block producer node and broadcasts it to other nodes.
[0079] Here, the selection of the block producer node varies according to the consensus algorithm and can include a leader block producer, an ordered block producer, a computing power competition block producer, etc.
[0080] In some embodiments, the node that obtains the transaction request by the RPC layer generates transaction data with a group identifier (i.e., the data of the transaction), broadcasts it to each other, and adds it to the transaction pool. When the block producer node packs a plurality of transactions into one block, the transaction data with the same group identifier is used as the group transaction data of the same group.
[0081] In step S3, after each node receives a block, it starts to execute the transaction in the block and performs logic calculation. In the logic calculation layer, the transaction parameters are analyzed and the contract is executed.
[0082] During the execution process, it may be necessary to read data in the memory space (i.e., read data). As shown in the example of FIG. 5, Node 1 reads historical transaction data from the memory space.
[0083] In some embodiments, when each node executes a transaction in a block, for the same group of group transaction data as a whole, each group transaction data in the group is executed in sequence to obtain the executed transaction execution result. If the executed transaction execution result includes a transaction execution failure result, all the transaction execution results corresponding to each group transaction data in the group are updated to the transaction execution failure result, thereby ensuring whether all the group transaction data in the group has been successfully executed or all have failed in execution.
[0084] In step S4, after the execution of the contract is completed, each node performs a mutual check on the execution result (i.e., the transaction execution result corresponding to each group transaction data above). As an inspection method, the execution result or the change to the memory is configured into the result merkle tree, and the result tree root (i.e., the result root hash) is put into the block header. Finally, it can be checked that the hash of each node block matches.
[0085] In step S5, after the consensus is successful, each node writes the related data of this block into the memory space.
[0086] Here, the related data includes the block header, all transactions included in the block, and the contract execution result, etc.
[0087] Regarding the detailed processes of steps S1 to S5 above, reference may be made to the embodiments corresponding to FIG. 3 and the embodiments corresponding to FIG. 4, and they will not be repeated here.
[0088] Referring to FIG. 6, FIG. 6 is a schematic diagram of an example of the realization scenario of the transaction group provided in the embodiment of the present application. Assuming that the participants in the multi-party cooperative transaction are Participant A, Participant B, and Participant C, Participant A generates transaction a, Participant B generates transaction b, and Participant C generates transaction c. In the method provided in the embodiment of the present application, these three transactions can be added to the same transaction group. When the blockchain system executes transactions and consensus, the transaction group is used as the minimum execution unit. All transactions in one transaction group must succeed simultaneously, thereby ensuring that the three parties of Participant A, Participant B, and Participant C each receive their respective transfers, or fail simultaneously, the money is returned to the original owner, and none of the parties suffer losses.
[0089] As shown in FIG. 6, a group number field can be added to a transaction request corresponding to a transaction. For example, the group number field in transaction request 61 corresponding to transaction a is "group identifier: 5, execution order identifier: 1, group transaction quantity: 3", where the group identifier of the transaction group to which the transaction request 61 belongs is 5, the transaction group contains three transactions, and it indicates that transaction a corresponding to transaction request 61 is the first transaction in the transaction group. Similarly, the group number field in transaction request 62 corresponding to transaction b is "group identifier: 5, execution order identifier: 2, group transaction quantity: 3", where the group identifier of the transaction group to which the transaction request 62 belongs is 5, the transaction group contains three transactions, and it indicates that transaction b corresponding to transaction request 62 is the second transaction in the transaction group. The group number field in transaction request 63 corresponding to transaction c is "group identifier: 5, execution order identifier: 3, group transaction quantity: 3", where the group identifier of the transaction group to which the transaction request 63 belongs is 5, the transaction group contains three transactions, and it indicates that transaction c corresponding to transaction request 63 is the third transaction in the transaction group. Here, the execution order identifier may be jointly determined in advance by three participants, or may be determined based on the start time of the transaction request, and is not limited thereto. Participant A, Participant B, and Participant C can obtain the group identifier for the current multi-party collaborative transaction in a plurality of ways. For example, it is the method of obtaining the group identifier described in step S202 in the embodiment corresponding to FIG. 4 above.
[0090] As shown in FIG. 6, after each participant obtains a group identifier, each participant issues a respective transaction request, signs it with their own private key to obtain signature data, and sends the transaction request and the signature data together to the blockchain system. The blockchain system verifies the received transaction request based on the signature data, then generates corresponding transaction data, and packs the transaction data with the same group identifier into the same proposed block as group transaction data. Understandably, if the collection of transaction data in a transaction group is not completed, the blockchain system waits for a certain period of time. Next, the blockchain system executes the proposed block and executes the transactions in units of transaction groups. If any transaction in a transaction group fails to execute, it can be recognized that the transaction group has failed, and the transaction execution results of the group transaction data corresponding to each transaction are all updated to transaction failure results. Finally, the blockchain system performs consensus and storage on the proposed block after execution. It should be noted that the acquisition of the group identifier can also be accomplished by the blockchain system. That is, the participants in a multi-party cooperative transaction do not need to obtain the group identifier and only need to send the transaction request to the blockchain system, and the blockchain system distributes the group identifier to the participants.
[0091] To better understand the realization process of a transaction group, referring to FIG. 7, FIG. 7 is a flowchart of an example of the realization of a transaction group provided in an embodiment of the present application. As shown in FIG. 7, the transaction data corresponding to the transactions generated by the terminal device 71 and the terminal device 72 are all put into the transaction pool and wait to be packed into the proposed block by the consensus node 73 serving as the block producer node. The consensus node 73 acts as a block producer according to the consensus algorithm. During that period, until it obtains the transaction data corresponding to all the transactions in the transaction group corresponding to the group identifier, the transaction data having the same group identifier is put into the group cache queue for caching, and all the transaction data in the complete group is packed into the proposed block as the group transaction data. Next, the consensus node 73 broadcasts the proposed block to other consensus nodes in the blockchain system. The consensus node 73 executes the group transaction data corresponding to each transaction group in the proposed block. For the specific execution process, reference may be made to the description of the embodiment corresponding to FIG. 3 above, and it will not be repeated here. After the consensus node 73 completes the execution of the proposed block and reaches a consensus with other consensus nodes on the proposed block, it notifies the result to the terminal device 71 and the terminal device 72.
[0092] Referring to FIG. 8, FIG. 8 is a schematic structural diagram of an example of a blockchain-based data processing apparatus provided in an embodiment of the present application. The data processing apparatus may be a computer program (including program code) executed on a computer device. For example, the data processing apparatus may be application software. The apparatus may be for executing corresponding steps in the data processing method provided in the embodiment of the present application. As shown in FIG. 8, the data processing apparatus 1 may include a group determination module 11, a packing module 12, a block execution module 13, a result update module 14, a block update module 15, and a bookkeeping module 16.
[0093] The group determination module 11 is configured to determine a plurality of transaction data having the same group identifier in the transaction pool as group transaction data.
[0094] The packing module 12 is configured to pack each of the group transaction data into a proposed block.
[0095] The block execution module 13 is configured to pack each of the group transaction data into a proposed block, execute each of the group transaction data in the proposed block, and obtain an executed transaction execution result.
[0096] When the executed transaction execution result includes a transaction execution failure result, the result update module 14 is configured to update any transaction execution result corresponding to each of the group transaction data to a transaction execution failure result.
[0097] The block update module 15 is configured to update the proposed block based on the transaction execution failure result corresponding to each of the group transaction data to obtain a target proposed block.
[0098] When the target proposal block is approved by consensus, the accounting module 16 is configured to perform accounting processing on the target proposal block and the transaction execution failure results corresponding to each of the group transaction data.
[0099] Here, for the specific implementation manners of the group decision module 11, the packing module 12, the block execution module 13, the result update module 14, the block update module 15, and the accounting module 16, reference may be made to the descriptions of steps S101 to S104 in the embodiment corresponding to FIG. 3 above, and details will not be repeated here.
[0100] Referring to FIG. 8, the group decision module 11 may include an acquisition unit 111, a data addition unit 112, a first decision unit 113, and a second decision unit 114.
[0101] The acquisition unit 111 is configured such that the consensus node acquires the transaction data from the transaction pool, and the transaction data includes a group identifier and a group transaction quantity. The data addition unit 112 is configured to add the transaction data to the group cache queue corresponding to the group identifier to obtain an updated group cache queue. The first decision unit 113 is configured to determine the transaction data in the updated group cache queue as group transaction data when the quantity of the transaction data in the updated group cache queue is equal to the group transaction quantity. The second decision unit 114 is configured to continuously acquire the transaction data including the group identifier from the transaction pool when the quantity of the transaction data in the updated group cache queue is smaller than the group transaction quantity.
[0102] Here, for the specific implementation manners of the acquisition unit 111, the data addition unit 112, the first determination unit 113, and the second determination unit 114, reference may be made to the description of step S101 in the embodiment corresponding to FIG. 3 above, and it will not be repeatedly described here.
[0103] Referring to FIG. 8, the second determination unit 114 may include a first determination subunit 1141 and a second determination subunit 1142.
[0104] The first determination subunit 1141 is configured to continuously acquire transaction data including the group identifier from the transaction pool when the quantity of transaction data in the update group cache queue is smaller than the group transaction quantity and the current time is within the cache time zone. The second determination subunit 1142 is configured to re-put the transaction data in the update group cache queue into the transaction pool and clear the update group cache queue when the quantity of transaction data in the update group cache queue is smaller than the group transaction quantity and the current time exceeds the cache time zone.
[0105] Here, for the specific implementation manners of the first determination subunit 1141 and the second determination subunit 1142, reference may be made to the description of step S101 in the embodiment corresponding to FIG. 3 above, and it will not be repeatedly described here.
[0106] Here, each group of transaction data all includes an execution order identifier. Referring to FIG. 8, the packing module 12 may include a sorting unit 121 and a packing unit 122.
[0107] The sorting unit 121 is configured to execute a sorting process on each of the group transaction data based on the execution order identifier included in each of the group transaction data, and obtain the sorted group transaction data. The packing unit 122 is configured to pack the sorted group transaction data into a proposal block.
[0108] Here, for the specific implementation manners of the sorting unit 121 and the packing unit 122, reference may be made to the description of step S102 in the embodiment corresponding to FIG. 3 above, and it will not be repeatedly described here.
[0109] Here, the quantity of the group transaction data is S, and S is a positive integer greater than 1. Referring to FIG. 8, the block execution module 13 may include a transaction execution unit 131, a first result determination unit 132, and a second result determination unit 133.
[0110] The transaction execution unit 131 is configured to obtain the k-th group transaction data in the proposal block, execute the k-th group transaction data, and obtain a transaction execution result corresponding to the k-th group transaction data, where k is a positive integer that increases sequentially and k is less than S. The first result determination unit 132 is configured to continue to execute the (k + 1)-th group transaction data in the proposal block when the transaction execution result corresponding to the k-th group transaction data is a transaction execution success result. The second result determination unit 133 is configured to determine that the transaction execution results corresponding to each of the (k + 1)-th group transaction data to the S-th group transaction data in the proposal block are all transaction execution failure results when the transaction execution result corresponding to the k-th group transaction data is a transaction execution failure result.
[0111] Here, for the specific implementation manners of the transaction execution unit 131, the first result determination unit 132, and the second result determination unit 133, reference may be made to the description of step S102 in the embodiment corresponding to FIG. 3 above, and details will not be repeated here.
[0112] Referring to FIG. 8, the block update module 15 may include a tree generation unit 151 and a tree addition unit 152.
[0113] The tree generation unit 151 is configured to generate a result Merkle tree based on the transaction execution failure results corresponding to each of the group transaction data, and the result Merkle tree includes a tree root hash value. The tree addition unit 152 is configured to add the tree root hash value to the block header of the proposed block to obtain a target proposed block.
[0114] Here, for the specific implementation manners of the tree generation unit 151 and the tree addition unit 152, reference may be made to the description of step S103 in the embodiment corresponding to FIG. 3 above, and details will not be repeated here.
[0115] Referring to FIG. 8, the data processing apparatus 1 may further include a broadcast module 17, a hash value processing module 18, and a consensus module 19.
[0116] The broadcast module 17 is configured to broadcast the proposed block to the communicable consensus nodes in the consensus network. The communicable consensus nodes execute each of the group transaction data in the proposed block, update the proposed block based on the transaction execution results corresponding to each of the group transaction data, and obtain a communicable target proposed block. The hash value processing module 18 is configured to receive the block hash value of the communicable target proposed block transmitted from the communicable consensus node and determine the block hash value of the communicable target proposed block as the matching target block hash value. The consensus module 19 is configured to determine that the target proposed block has been approved by consensus when the quantity of the matching target block hash values that are the same as the block hash value of the target proposed block is greater than the consensus quantity threshold.
[0117] Here, for the specific implementation manners of the broadcast module 17, the hash value processing module 18, and the consensus module 19, reference may be made to the description of step S104 in the embodiment corresponding to FIG. 3 above, and it will not be repeated here.
[0118] Referring to FIG. 9, FIG. 9 is a schematic structural diagram of an example of a computer device provided in an embodiment of the present application. As shown in FIG. 9, the data processing device 1 in the embodiment corresponding to FIG. 8 above can be applied to the computer device 1000 above. The computer device 1000 above can include a processor 1001, a network interface 1004, and a memory 1005. In addition, the computer device 1000 above further includes a user interface 1003 and at least one communication bus 1002. Here, the communication bus 1002 is for realizing connection communication between these components. Here, the user interface 1003 can include a display and a keyboard, and optionally, the user interface 1003 can further include a standard wired interface and a wireless interface. The network interface 1004 can include a standard wired interface and a wireless interface (for example, a WI-FI interface). The memory 1005 can be a high-speed RAM memory and can also be a non-volatile memory, for example, at least one disk memory. The memory 1005 can further be at least one storage device separated from the processor 1001 above. As shown in FIG. 9, as a type of computer-readable storage medium, the memory 1005 can include an operating system, a network communication module, a user interface module, and a device control application program.
[0119] In the computer device 1000 shown in FIG. 9, the network interface 1004 can provide a network communication function. The user interface 1003 is mainly for providing an input interface to the user. The processor 1001 is for calling the device control application program stored in the memory 1005 to realize the following steps.
[0120] Determine a plurality of transaction data having the same group identifier in a transaction pool as group transaction data, pack each said group transaction data into a proposal block, execute each said group transaction data in the proposal block, obtain an executed transaction execution result, and if the executed transaction execution result includes a transaction execution failure result, update all the transaction execution results corresponding to each said group transaction data to transaction execution failure results, update the proposal block based on the transaction execution failure results corresponding to each said group transaction data, obtain a target proposal block, and if the target proposal block is approved by consensus, perform accounting processing on the target proposal block and the transaction execution failure results corresponding to each said group transaction data.
[0121] Understandably, the computer device 1000 described in the embodiments of the present application can execute the description of the data processing method in each of the foregoing embodiments, and can describe the data processing apparatus 1 in the embodiment corresponding to FIG. 8 above, which will not be repeated here. Furthermore, the description of the beneficial effects of adopting the same method will not be repeated here.
[0122] Furthermore, it should be noted here that the embodiments of the present application further provide a computer-readable storage medium. The above computer-readable storage medium stores a computer program executed by the foregoing data processing apparatus 1. When the above processor loads and executes the above computer program, it can execute the description of the above data processing method in any of the foregoing embodiments. Therefore, it will not be repeated here. Furthermore, the description of the beneficial effects of adopting the same method will not be repeated here. For technical details not disclosed in the computer-readable storage medium embodiments of the present application, reference may be made to the description of the method embodiments of the present application.
[0123] Referring to FIG. 10, FIG. 10 is a schematic structural diagram of another example of a blockchain-based data processing apparatus provided in an embodiment of the present application. The above data processing apparatus can be a computer program (including program code) executed on a computer device. For example, the data processing apparatus can be application software. The data processing apparatus can be for executing corresponding steps in the method provided in the embodiment of the present application. As shown in FIG. 10, the data processing apparatus 2 can include a request receiving module 21, an identifier determining module 22, and a data adding module 23.
[0124] The request receiving module 21 is configured to receive a transaction request for a multi-party cooperation transaction transmitted from a terminal device.
[0125] The identifier determining module 22 is configured to determine a group identifier corresponding to the multi-party cooperation transaction based on the transaction request.
[0126] The data adding module 23 is configured to generate transaction data having a group identifier based on the group identifier corresponding to the multi-party cooperation transaction and the transaction request, and add the transaction data to a transaction pool.
[0127] Here, the transaction pool has a plurality of transaction data with the same group identifier, and the transaction data is for being determined as group transaction data by a consensus node. The consensus node packs each of the group transaction data into a proposed block, executes each of the group transaction data in the proposed block, and is for obtaining an executed transaction execution result. When the executed transaction execution result includes a transaction execution failure result, the consensus node further updates any transaction execution result corresponding to each of the group transaction data to a transaction execution failure result.
[0128] Here, for the specific implementation manners of the request receiving module 21, the identifier determining module 22, and the data adding module 23, reference may be made to the descriptions of steps S201 to S203 in the embodiment corresponding to FIG. 4 above, and details are not repeated here.
[0129] Here, the transaction request carries signature data, and the signature data is obtained after the terminal device performs signature processing on the transaction request with a private key. Referring to FIG. 10, the data processing device 2 may further include a signature module 24.
[0130] The signature module 24 is configured to obtain a public key corresponding to the terminal device. The signature module 24 is further configured to perform signature verification processing on the signature data with the public key to obtain a signature verification result. When the signature verification result is a signature verification success result, the signature module 24 is further configured to notify the identifier determining module 22 to determine a group identifier corresponding to a multi-party cooperative transaction based on the transaction request.
[0131] Here, for the specific implementation method of the signature module 24, reference may be made to the description of step S202 in the embodiment corresponding to FIG. 4 above, and it will not be repeated here.
[0132] Here, the number of the transaction requests is plural, and each of the transaction requests includes an execution order identifier. Referring to FIG. 10, the identifier determination module 22 may include a first identifier determination unit 221.
[0133] When the first identifier determination unit 221 obtains a transaction request with the highest order priority indicated by the execution order identifier, the first identifier determination unit 221 is configured to determine the transaction request with the highest order priority as a group identifier request. The first identifier determination unit 221 is further configured to perform a hash process on the group identifier request to obtain a request hash value, and determine the request hash value as the group identifier corresponding to the multi-party cooperative transaction.
[0134] Here, for the specific implementation method of the first identifier determination unit 221, reference may be made to the description of step S202 in the embodiment corresponding to FIG. 4 above, and it will not be repeated here.
[0135] Here, the transaction request includes a cooperative transaction start object that starts a multi-party cooperative transaction. Referring to FIG. 10, the identifier determination module 22 may include a second identifier determination unit 222.
[0136] The second identifier determination unit 222 is configured to obtain the cooperative transaction start object from the transaction request. The second identifier determination unit 222 is further configured to search an identity identifier library for an identity identifier corresponding to the cooperative transaction start object. The second identifier determination unit 222 is further configured to generate a group identifier corresponding to the multi-party cooperative transaction based on the identity identifier.
[0137] Here, regarding the specific implementation manner of the second identifier determination unit 222, reference may be made to the description of step S202 in the embodiment corresponding to FIG. 4 above, and it will not be repeatedly described here.
[0138] Referring to FIG. 10, the data processing apparatus 2 may further include an identifier generation module 25.
[0139] The identifier generation module 25 is configured to obtain an identifier acquisition request for a multi-party cooperative transaction started by a cooperative transaction start object. Here, the identifier acquisition request includes a transaction object participating in the multi-party cooperative transaction. The identifier generation module 25 is further configured to generate an available group identifier for the multi-party cooperative transaction based on the identifier acquisition request. The identifier generation module 25 is further configured to transmit the available group identifier to a terminal device corresponding to the transaction object. Here, the terminal device corresponding to the transaction object generates a transaction request including the available group identifier.
[0140] The identifier determination module 22 may include a third identifier determination unit 223.
[0141] The third identifier determination unit 223 is configured to determine the available group identifier in the transaction request as the group identifier corresponding to the multi-party cooperative transaction.
[0142] Here, regarding the specific implementation manners of the identifier generation module 25 and the third identifier determination unit 223, reference may be made to the description of step S202 in the embodiment corresponding to FIG. 4 above, and it will not be repeatedly described here.
[0143] Referring to FIG. 11, FIG. 11 is a schematic structural diagram of another example of the computer device provided in the embodiment of the present application. As shown in FIG. 11, the data processing device 2 in the embodiment corresponding to the above FIG. 10 can be applied to the above computer device 2000. The above computer device 2000 can include a processor 2001, a network interface 2004, and a memory 2005. In addition, the above computer device 2000 further includes a user interface 2003 and at least one communication bus 2002. Here, the communication bus 2002 is for realizing connection communication between these components. Here, the user interface 2003 can include a display and a keyboard, and optionally, the user interface 2003 can further include a standard wired interface and a wireless interface. The network interface 2004 can include a standard wired interface and a wireless interface (for example, a WI-FI interface). The memory 2005 can be a high-speed RAM memory and can also be a non-volatile memory, for example, at least one disk memory. The memory 2005 can further be at least one storage device separated from the above processor 2001. As shown in FIG. 11, as a kind of computer-readable storage medium, the memory 2005 can include an operating system, a network communication module, a user interface module, and a device control application program.
[0144] In the computer device 2000 shown in FIG. 11, the network interface 2004 can provide a network communication function. The user interface 2003 is mainly for providing an input interface for the user. The processor 2001 is for calling the device control application program stored in the memory 2005 to realize the following steps.
[0145] Receiving a transaction request for a multi-party collaborative transaction sent from a terminal device, determining a group identifier corresponding to the multi-party collaborative transaction based on the transaction request, generating transaction data having the group identifier based on the group identifier corresponding to the multi-party collaborative transaction and the transaction request, and adding the transaction data to a transaction pool.
[0146] Here, the transaction pool has a plurality of transaction data with the same group identifier, and the transaction data is for being determined as group transaction data by a consensus node. The consensus node packs each of the group transaction data into a proposal block, executes each of the group transaction data in the proposal block, and is for obtaining an executed transaction execution result. Further, when the executed transaction execution result includes a transaction execution failure result, the consensus node is for updating any transaction execution result corresponding to each of the group transaction data to a transaction execution failure result.
[0147] Understandably, the computer device 2000 described in the embodiments of the present application can execute the description of the data processing method in each of the foregoing embodiments, and can describe the data processing apparatus 2 in the embodiment corresponding to FIG. 10 above, which will not be repeatedly described here. Further, the description of the beneficial effects of adopting the same method will not be repeatedly described.
[0148] Furthermore, it should be noted here that the embodiments of the present application further provide a computer-readable storage medium. The computer-readable storage medium stores a computer program to be executed by the aforementioned data processing device 2. When the above-mentioned processor loads and executes the computer program, it can execute the description of the above-mentioned data processing method in any of the foregoing embodiments. Therefore, it will not be repeated here. Furthermore, the description of the beneficial effects of adopting the same method will not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium associated with the present application, reference may be made to the description of the method embodiments of the present application.
[0149] The above-mentioned computer-readable storage medium may be an internal storage unit of the data processing device provided in any of the foregoing embodiments or the above-mentioned computer device, for example, a hard disk or a memory of the computer device. The computer-readable storage medium may further be an external storage device of the computer device, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. arranged in the computer device. The computer-readable storage medium may further include both the internal storage unit and the external storage device of the computer device. The computer-readable storage medium is for storing the computer program and other programs and data required by the computer device. The computer-readable storage medium may further be for temporarily storing output or to-be-output data.
[0150] Furthermore, it should be noted that the embodiments of the present application further provide a computer program product or a computer program including computer instructions. The computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to enable the computer device to implement the method provided in any of the foregoing corresponding embodiments.
[0151] In the description, claims, and drawings of the embodiments of this application, the terms "first" and "second" do not describe a specific order but distinguish different objects. Furthermore, the term "comprising" or any other variation thereof is intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units not only includes those listed but also optionally includes steps or modules not listed, or the inherent steps or units of such a process, method, apparatus, product, or device.
[0152] As can be understood by those skilled in the art, the units and algorithm steps in each example described with reference to the embodiments disclosed in this specification can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, in the above description, the configurations and steps of each example have been generally described according to network elements. Whether these network elements are executed by hardware or software depends on the specific application of the technical solution and design constraints. Those skilled in the art can implement the network elements described in different ways for each specific application, but such implementation should not exceed the scope of this application.
[0153] What is disclosed above is only the optimal embodiment of this application and, of course, does not limit the scope of the claims of this application. Therefore, equivalent substitutions based on the claims of this application should be included within the protection scope of this application.
Claims
1. A blockchain-based data processing method executed by a computer device, wherein the computer device is mapped as a consensus node in a blockchain network, and the blockchain-based data processing method includes: A step in which the consensus node determines a plurality of transaction data having the same group identifier in a transaction pool as group transaction data; A step of packing each of the group transaction data into a proposed block, executing each of the group transaction data in the proposed block, and obtaining an executed transaction execution result; If the executed transaction execution result includes a transaction execution failure result, updating all the transaction execution results corresponding to each of the group transaction data to a transaction execution failure result, and generating a result Merkle tree including a tree root hash value based on the transaction execution failure result corresponding to each of the group transaction data, adding the tree root hash value to a block header of the proposed block, and obtaining a target proposed block; A step of performing accounting processing on the target proposed block and the transaction execution failure results corresponding to each of the group transaction data when the target proposed block is approved by consensus. A blockchain-based data processing method.
2. The step in which the consensus node determines a plurality of transaction data having the same group identifier in a transaction pool as group transaction data includes: A step in which the consensus node obtains the transaction data from the transaction pool, where the transaction data includes a group identifier and a group transaction quantity; The step of adding the transaction data to a group cache queue corresponding to the group identifier to obtain an updated group cache queue; When the quantity of transaction data in the updated group cache queue is equal to the group transaction quantity, the step of determining the transaction data in the updated group cache queue as group transaction data; When the quantity of transaction data in the updated group cache queue is less than the group transaction quantity, the step of continuously obtaining transaction data including the group identifier from the transaction pool, including: The blockchain-based data processing method according to claim 1.
3. When the quantity of transaction data in the updated group cache queue is less than the group transaction quantity, the step of continuously obtaining transaction data including the group identifier from the transaction pool: When the quantity of transaction data in the updated group cache queue is less than the group transaction quantity and the current time is within the cache time zone, the step of continuously obtaining transaction data including the group identifier from the transaction pool; The blockchain-based data processing method further includes: When the quantity of transaction data in the updated group cache queue is less than the group transaction quantity and the current time exceeds the cache time zone, the step of putting the transaction data in the updated group cache queue back into the transaction pool and clearing the updated group cache queue; The blockchain-based data processing method according to claim 2.
4. Each of the group transaction data includes an execution order identifier. The step of packing each of the group transaction data into a proposal block includes executing a sorting process on each of the group transaction data based on the execution order identifier included in each of the group transaction data to obtain the sorted group transaction data; and packing the sorted group transaction data into a proposal block. The data processing method based on the blockchain according to claim 1.
5. The quantity of the group transaction data is S, where S is a positive integer greater than 1. The step of executing each of the group transaction data in the proposal block to obtain an executed transaction execution result includes obtaining the k-th group transaction data in the proposal block, executing the k-th group transaction data, and obtaining a transaction execution result corresponding to the k-th group transaction data, where k is a positive integer that increases sequentially and k is less than S; when the transaction execution result corresponding to the k-th group transaction data is a transaction execution success result, continuously executing the (k + 1)-th group transaction data in the proposal block; when the transaction execution result corresponding to the k-th group transaction data is a transaction execution failure result, determining that the transaction execution results corresponding to each of the (k + 1)-th group transaction data to the S-th group transaction data in the proposal block are all transaction execution failure results; and setting the transaction execution result corresponding to each of the group transaction data as the executed transaction execution result. The data processing method based on blockchain according to claim 1.
6. The data processing method based on the blockchain further includes broadcasting the proposed block to consensus nodes communicable in the consensus network, where the communicable consensus nodes execute each group transaction data in the proposed block, and update the proposed block based on the transaction execution result corresponding to each group transaction data to obtain a communicable target proposed block; receiving the block hash value of the communicable target proposed block transmitted from the communicable consensus node, and determining the block hash value of the communicable target proposed block as the matching target block hash value; when the quantity of matching target block hash values the same as the block hash value of the target proposed block is greater than the consensus quantity threshold, determining that the target proposed block has been approved by consensus. The data processing method based on blockchain according to claim 1.
7. A data processing method based on blockchain executed by a computer device, where the computer device is mapped as a service node in a blockchain network, and the data processing method based on the blockchain includes receiving, by the service node, a transaction request for a multi-party cooperative transaction transmitted from a terminal device; determining, based on the transaction request, a group identifier corresponding to the multi-party cooperative transaction; generating transaction data having the group identifier based on the group identifier corresponding to the multi-party cooperative transaction and the transaction request, and adding the transaction data to a transaction pool. The transaction pool has a plurality of transaction data with the same group identifier, and the transaction data is for being determined as group transaction data by a consensus node. The consensus node packs each of the group transaction data into a proposed block, executes each of the group transaction data in the proposed block, and obtains an executed transaction execution result. When the executed transaction execution result includes a transaction execution failure result, the consensus node further updates any transaction execution result corresponding to each of the group transaction data to a transaction execution failure result, generates a result Merkle tree including a tree root hash value based on the transaction execution failure result corresponding to each of the group transaction data, adds the tree root hash value to a block header of the proposed block, and obtains a target proposed block. A data processing method based on a blockchain.
8. The transaction request carries signature data, and the signature data is obtained after the terminal device performs signature processing on the transaction request with a private key. The data processing method based on the blockchain further includes: obtaining a public key corresponding to the terminal device; performing signature verification processing on the signature data with the public key to obtain a signature verification result; when the signature verification result is a signature verification success result, executing a step of determining a group identifier corresponding to the multi-party cooperative transaction based on the transaction request. The data processing method based on the blockchain according to claim 7.
9. The number of the transaction requests is plural, and each of the transaction requests includes an execution order identifier. The step of determining a group identifier corresponding to the multi-party cooperative transaction based on the transaction request includes: When obtaining a transaction request with the highest priority order indicated by the execution order identifier, determining the transaction request with the highest priority order as a group identifier request; Performing a hash process on the group identifier request to obtain a request hash value, and determining the request hash value as a group identifier corresponding to the multi-party cooperative transaction. The data processing method based on the blockchain according to claim 7.
10. The transaction request includes a cooperative transaction start object that starts the multi-party cooperative transaction. The step of determining a group identifier corresponding to the multi-party cooperative transaction based on the transaction request includes: Obtaining the cooperative transaction start object from the transaction request; Searching an identifier library for an identifier corresponding to the cooperative transaction start object; Generating a group identifier corresponding to the multi-party cooperative transaction based on the identifier. The data processing method based on the blockchain according to claim 7.
11. The data processing method based on the blockchain further includes: Obtaining an identifier acquisition request for a multi-party cooperative transaction started by a cooperative transaction start object, where the identifier acquisition request includes a transaction object participating in the multi-party cooperative transaction; Generating an available group identifier for the multi-party cooperative transaction based on the identifier acquisition request. A step of transmitting the usable group identifier to a terminal device corresponding to the transaction object, wherein the terminal device corresponding to the transaction object generates a transaction request including the usable group identifier, and, The step of determining a group identifier corresponding to the multi-party cooperative transaction based on the transaction request is, Including the step of determining the usable group identifier in the transaction request as the group identifier corresponding to the multi-party cooperative transaction. The blockchain-based data processing method according to claim 7.
12. A data processing apparatus based on a blockchain, A group determination module configured to determine a plurality of transaction data having the same group identifier in a transaction pool as group transaction data, A packing module configured to pack each of the group transaction data into a proposal block, A block execution module configured to execute each of the group transaction data in the proposal block and obtain an executed transaction execution result, A result update module configured to update any transaction execution result corresponding to each of the group transaction data to a transaction execution failure result when the executed transaction execution result includes a transaction execution failure result, Based on the transaction execution failure result corresponding to each of the group transaction data, a result Merkle tree including a tree root hash value is generated, the tree root hash value is added to the block header of the proposal block, and a target proposal block is obtained. A block update module configured to, When the target proposed block is approved by consensus, a bookkeeping module configured to perform bookkeeping processing on the target proposed block and transaction execution failure results corresponding to each of the group transaction data. A data processing apparatus based on a blockchain, including the bookkeeping module.
13. A data processing apparatus based on a blockchain, comprising: A request receiving module configured to receive a transaction request for a multi-party cooperative transaction transmitted from a terminal device; An identifier determination module configured to determine a group identifier corresponding to the multi-party cooperative transaction based on the transaction request; A data addition module configured to generate transaction data having a group identifier based on the group identifier corresponding to the multi-party cooperative transaction and the transaction request, and add the transaction data to a transaction pool. The transaction pool has a plurality of transaction data with the same group identifier, and the transaction data is for being determined as group transaction data by a consensus node. The consensus node packs each of the group transaction data into a proposed block, executes each of the group transaction data in the proposed block to obtain an executed transaction execution result. The consensus node further, when the executed transaction execution result includes a transaction execution failure result, updates all the transaction execution results corresponding to each of the group transaction data to the transaction execution failure result, generates a result Merkle tree including a tree root hash value based on the transaction execution failure result corresponding to each of the group transaction data, adds the tree root hash value to a block header of the proposed block, and is for obtaining a target proposed block. A data processing apparatus based on a blockchain.
14. A computer device including a processor, a memory, and a network interface, wherein the processor is connected to the memory and the network interface, the network interface is for providing a data communication function, the memory is for storing program code, and the processor is for calling the program code to execute the data processing method based on the blockchain according to any one of claims 1 to 11. A computer device.
15. A computer program for causing a computer to execute the data processing method based on the blockchain according to any one of claims 1 to 11.
Citation Information
Patent Citations
Block chain-based data transaction method, system and device
CN112565412A
Block consensus method based on block chain and related equipment
CN112685796A
Parallel execution of transactions in a blockchain network
JP2020515942A
Computer-implemented system and method for managing large-scale distributed memory pools in a blockchain network
JP2020528607A
Asset management method and apparatus, and electronic device
JP2021511561A