Transaction processing method and device based on block chain, equipment and medium

Abstract

The embodiment of the invention discloses a transaction processing method and device based on a block chain, equipment and a medium, which can be applied to various scenes such as intelligent traffic, auxiliary driving, cloud technology and artificial intelligence. The method comprises the following steps: receiving a transaction request sent by a client, and taking the transaction request as a to-be-broadcasted transaction request; obtaining proposal data corresponding to the to-be-consensus transaction request; generating a proposal request based on the proposal data and the transaction request to be broadcasted; and sending the proposal request to the block chain node, thereby enabling the block chain node to obtain a to-be-broadcasted transaction request from the proposal request, and performing consensus on the to-be-consensus transaction request based on proposal data in the proposal request. According to the technical scheme, the transaction processing efficiency and accuracy are improved, and the transaction processing scheme is greatly optimized.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically, to a blockchain-based transaction processing method, a blockchain-based transaction processing device, an electronic device, and a computer-readable medium. Background Art

[0002] A blockchain system is a database system that stores data on different blockchain nodes and accesses them through a network connection. In this type of database, each blockchain node maintains data by reaching a consensus.

[0003] It's understandable that the blockchain transaction process typically involves transaction broadcast and consensus. Both processes involve broadcasting the corresponding transaction message. This not only results in duplicate broadcasts of transaction messages, reducing transaction processing efficiency, but also wastes network resources. Furthermore, in poor network conditions, failure to broadcast the corresponding transaction message can lead to failures in transaction broadcast or consensus, reducing transaction processing accuracy.

[0004] Therefore, how to improve the reliability of transaction processing is an urgent problem to be solved. Summary of the Invention

[0005] The embodiments of the present application provide a blockchain-based transaction processing method, apparatus, device, and medium, which improve the efficiency and accuracy of transaction processing, save network resources, and increase the reliability of transaction processing.

[0006] In a first aspect, an embodiment of the present application provides a transaction processing method based on blockchain, the method comprising: receiving a transaction request sent by a client, and using the transaction request as a transaction request to be broadcast; obtaining proposal data corresponding to the transaction request to be agreed upon; generating a proposal request based on the proposal data and the transaction request to be broadcast; sending the proposal request to a blockchain node, so that the blockchain node obtains the transaction request to be broadcast from the proposal request, and reaches consensus on the transaction request to be agreed upon based on the proposal data in the proposal request.

[0007] In a second aspect, an embodiment of the present application provides a transaction processing device based on blockchain, the device comprising: a receiving module, configured to receive a transaction request sent by a client, and use the transaction request as a transaction request to be broadcast; an acquisition module, configured to obtain proposal data corresponding to the transaction request to be agreed upon; a generation module, configured to generate a proposal request based on the proposal data and the transaction request to be broadcast; a sending module, configured to send the proposal request to a blockchain node, so that the blockchain node obtains the transaction request to be broadcast from the proposal request, and reaches consensus on the transaction request to be agreed upon based on the proposal data in the proposal request.

[0008] In one embodiment of the present application, based on the aforementioned solution, the transaction requests to be broadcast include multiple ones; the generation module is specifically configured to: combine the multiple transaction requests to be broadcast to obtain a transaction broadcast group; encapsulate the proposal data and the transaction broadcast group to generate a proposal request.

[0009] In one embodiment of the present application, based on the aforementioned solution, the device further includes: an adding module configured to add the transaction request to be broadcast to the transaction pool; accordingly, the first acquisition module is specifically configured to: obtain the transaction request to be agreed upon; wherein, the transaction request to be agreed upon includes the transaction request to be broadcast, and at least one of the other transaction requests in the transaction pool, and the other transaction request is a transaction request other than the transaction request to be broadcast; and generate proposal data corresponding to the transaction request to be agreed upon based on the transaction request to be agreed upon.

[0010] In one embodiment of the present application, based on the aforementioned scheme, the transaction requests to be agreed upon include multiple ones; the generation module is specifically configured to: combine the multiple transaction requests to be agreed upon to obtain a transaction consensus group; perform a signing operation on the transaction consensus group to obtain signature data corresponding to the transaction consensus group; and generate proposal data corresponding to the transaction consensus group based on the signature data and the transaction consensus group.

[0011] In one embodiment of the present application, based on the aforementioned scheme, the generation module is further specifically configured to: obtain the transaction execution order between multiple transaction requests to be agreed upon in the transaction consensus group; based on the transaction execution order and the signature data, generate proposal data corresponding to the transaction consensus group; wherein, the transaction execution order is used by the blockchain node to perform verification operations on the transaction execution order to complete the consensus of the transaction consensus group.

[0012] In one embodiment of the present application, based on the aforementioned scheme, the blockchain node includes multiple nodes; the device also includes: a first determination module, configured to determine a first target blockchain node that has passed the sequential verification of the transaction execution from multiple blockchain nodes; a second determination module, configured to determine that the consensus of the transaction consensus group has passed if the number of the first target blockchain nodes reaches a first preset number threshold.

[0013] In one embodiment of the present application, based on the aforementioned scheme, the generation module is further specifically configured to: execute multiple transaction requests to be agreed upon in the transaction consensus group to obtain a transaction execution result; based on the transaction execution result and the signature data, generate proposal data corresponding to the transaction consensus group; wherein, the transaction execution result is used by the blockchain node to perform a verification operation on the transaction execution result to complete the consensus of the transaction consensus group.

[0014] In one embodiment of the present application, based on the aforementioned scheme, the blockchain node includes multiple nodes; the device also includes: a third determination module, configured to determine a second target blockchain node that has passed the verification of the transaction execution result from multiple blockchain nodes; a fourth determination module, configured to determine that the consensus of the transaction consensus group has passed if the number of the second target blockchain nodes reaches a second preset number threshold.

[0015] In one embodiment of the present application, based on the aforementioned solution, the device further includes: a second acquisition module, configured to, if a consensus result indicating that the consensus on the transaction request to be agreed upon is passed, obtain a block generated based on the transaction execution result corresponding to the transaction request to be agreed upon; and a storage module, configured to store the block on the blockchain.

[0016] In one embodiment of the present application, based on the aforementioned scheme, the device further includes: an extraction module, configured to extract transaction requests received within a preset time period before the current time point from the transaction pool; a third acquisition module, configured to obtain broadcast credential information corresponding to the extracted transaction request; wherein, the broadcast credential information is generated based on the voting information corresponding to the extracted transaction request, and the voting information is generated in response to the reception status of the extracted transaction request when the extracted transaction request is broadcast; a second sending module, configured to send the broadcast credential information to the blockchain node, so that the blockchain node detects the storage status corresponding to the extracted transaction request based on the broadcast credential information.

[0017] In one embodiment of the present application, based on the aforementioned scheme, the device further includes: a second receiving module, configured to receive an acquisition request corresponding to the missing transaction request sent by the blockchain node; wherein the acquisition request is generated by the blockchain node after detecting that there is a missing transaction request based on the broadcast credential information; a third sending module, configured to send the missing transaction request to the blockchain node, so that the blockchain node performs synchronization operations on the missing transaction request.

[0018] In a third aspect, an embodiment of the present application provides an electronic device comprising one or more processors; and a memory for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the blockchain-based transaction processing method as described above.

[0019] In a fourth aspect, an embodiment of the present application provides a computer-readable medium on which a computer program is stored, and when the computer program is executed by a processor, the blockchain-based transaction processing method as described above is implemented.

[0020] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising computer instructions, which, when executed by a processor, implement the blockchain-based transaction processing method as described above.

[0021] In the technical solution provided in the embodiments of the present application, a proposal request is jointly generated based on the transaction request to be broadcast and the proposal data corresponding to the transaction request to be agreed upon. Thus, the transaction request to be broadcast can be obtained from the proposal request to implement the corresponding transaction broadcast, and the proposal data corresponding to the transaction request to be agreed upon can be obtained from the proposal request to implement the corresponding transaction consensus. This integrates the transaction broadcast and transaction consensus proposal stages, so the transaction corresponding message only needs to be broadcast once, avoiding the phenomenon of repeated broadcasting of the transaction corresponding message, improving the efficiency of transaction processing, and saving network resources. It also avoids the phenomenon of transaction broadcast or transaction consensus failure due to the failure of the transaction corresponding message broadcast, improving the accuracy of transaction processing, and further improving the efficiency of transaction processing, that is, the reliability of transaction processing is high.

[0022] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1A It is a structural diagram of the data sharing system.

[0024] Figure 1B It is a schematic diagram of the connection relationship between each block in the blockchain.

[0025] Figure 1CThis is a schematic diagram of the generation of blocks in the blockchain.

[0026] Figure 2A It is a schematic diagram of a blockchain transaction process shown in an exemplary embodiment of the present application.

[0027] Figure 2B It is a schematic diagram of transaction broadcasting shown in an exemplary embodiment of the present application.

[0028] Figure 2C It is a schematic diagram of a transaction consensus shown in an exemplary embodiment of the present application.

[0029] Figure 3A It is a schematic diagram of an exemplary implementation environment in which the technical solutions of the embodiments of the present application can be applied.

[0030] Figure 3B It is a schematic diagram of a blockchain transaction process shown in another exemplary embodiment of the present application.

[0031] Figure 4 This is a flowchart of a blockchain-based transaction processing method shown in an exemplary embodiment of the present application.

[0032] Figure 5 It is a flowchart of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application.

[0033] Figure 6 It is a flowchart of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application.

[0034] Figure 7 It is a flowchart of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application.

[0035] Figure 8 It is a flowchart of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application.

[0036] Figure 9 It is a schematic diagram of a blockchain-based transaction processing method shown in another exemplary embodiment of the present application.

[0037] Figure 10 This is a schematic diagram illustrating an exemplary embodiment of the present application for implementing transaction request detection using a checkpoint mechanism.

[0038] Figure 11 It is a schematic diagram of a detection scenario 1 shown in an exemplary embodiment of the present application.

[0039] Figure 12 It is a schematic diagram of detection scenario 2 shown in an exemplary embodiment of the present application.

[0040] Figure 13 It is a schematic diagram of detection scenario 3 shown in an exemplary embodiment of the present application.

[0041] Figure 14 It is a schematic diagram of detection scene 4 shown in an exemplary embodiment of the present application.

[0042] Figure 15 It is a block diagram of a blockchain-based transaction processing device shown as an exemplary embodiment of the present application.

[0043] Figure 16 It is a structural diagram of a computer system suitable for implementing the electronic device of the embodiment of the present application. DETAILED DESCRIPTION

[0044] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments applicable to the present application. Rather, they are merely examples of apparatus and methods applicable to certain aspects of the present application, as detailed in the appended claims.

[0045] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0046] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0047] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0048] It should be noted that the term "plurality" used in this application refers to two or more. "And / or" describes the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A alone, A and B together, or B alone. The character " / " generally indicates that the associated objects are in an "or" relationship.

[0049] Before introducing the technical solutions of the embodiments of the present application, the nouns and terms involved in the embodiments of the present application are first explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0050] Blockchain: A distributed ledger technology in the field of information technology, generally composed of consensus, transaction blocks and status data storage, cryptographic identity security, etc. Because the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being tamper-proof, traceable, and jointly maintained.

[0051] Smart contract: A computer protocol designed to communicate, verify, or execute contracts in an information-based manner, allowing for trusted transactions without a third party. A smart contract is a code deployed on a blockchain to perform a specific function.

[0052] Transaction pool: A pool within the blockchain that temporarily stores transactions. Each transaction waiting to be generated is first stored in the transaction pool and prioritized. When a new block is generated, transactions are retrieved from the transaction pool in order. The blockchain then executes and verifies the transactions. Once all nodes have verified the transactions, the transactions in the block are removed from the transaction pool.

[0053] Signature data: also known as digital signature or public key digital signature, is a digital string generated by the sender of the information that cannot be forged by others. It is an effective proof of the authenticity of the information sent by the sender.

[0054] Signature verification: The receiver needs to confirm whether the ciphertext file it receives is indeed sent by the sender, and whether it has been tampered with (different from decryption). The signature verification is ultimately based on the message digest for comparison.

[0055] Secondly, the blockchain technology used in the embodiments of this application is introduced in detail.

[0056] See also Figure 1AThe data sharing system (also referred to as a blockchain system) 100 shown is a system for sharing data between nodes (also referred to as blockchain nodes, hereinafter the same). The blockchain system may include multiple nodes 101, each of which may be a server or a terminal device. Each node may receive input information during normal operation and maintain the shared data within the blockchain system based on the received input information. To ensure information interoperability within the blockchain system, information connections may exist between each node in the blockchain system, and information can be transmitted between nodes through these information connections. For example, when any node in the blockchain system receives input information, other nodes in the blockchain system obtain the input information according to the consensus algorithm and store the input information as data in the shared data, ensuring that the data stored on all nodes in the blockchain system is consistent.

[0057] Each node in a blockchain system has a corresponding node identifier, and each node in the blockchain system can store the node identifiers of other nodes in the blockchain system, so that generated blocks can be broadcast to other nodes in the blockchain system based on the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier in the node identifier list. The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify the node. Table 1 only uses the IP address as an example.

[0058] Node Name Node ID Node 1 xxx.xxx.xxx.xxx Node 2 xxx.xxx.xxx.xxx … … Node N xxx.xxx.xxx.xxx

[0059] Table 1

[0060] Each node in the blockchain system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 1B The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block uses the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0061] When generating each block in the blockchain, see Figure 1CWhen the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried. The eigenvalue calculation is performed multiple times so that the calculated eigenvalue can satisfy the following formula:

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

[0063] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0064] Once a random number that satisfies the above formula is calculated, the information can be stored accordingly, generating a block header and block body, thus obtaining the current block. Subsequently, the blockchain node sends the newly generated block to the other nodes in the blockchain system based on their node identifiers. These other nodes then verify the newly generated block and, upon completion, add it to their stored blockchain.

[0065] The aforementioned blockchains are generally divided into three types: public blockchain, private blockchain, and consortium blockchain. Furthermore, combinations of these types are possible, such as private blockchain + consortium blockchain, or consortium blockchain + public blockchain.

[0066] Public blockchains are the most decentralized. Participants (also known as nodes) in a public blockchain can access data records, participate in transactions, and compete for the right to record new blocks. Furthermore, each node can freely join or exit the blockchain system and perform related operations.

[0067] In contrast, a private blockchain system's write permissions are controlled by a specific organization or institution, while data read permissions are regulated by that organization. Simply put, a private blockchain can be a weakly centralized system with strict node restrictions and a small number of nodes. This type of blockchain is more suitable for internal use within a specific organization.

[0068] Consortium blockchains are a cross between public and private blockchains, enabling partial decentralization. Each node in a consortium chain typically has a corresponding entity or organization. Nodes are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain system.

[0069] Understandably, see Figure 2A , the blockchain transaction process usually includes transaction broadcast and transaction consensus; among them:

[0070] Transaction broadcasting means that the client sends a transaction request to a node in the blockchain system, and then this node broadcasts the transaction request to other nodes in the blockchain system, so that each node in the blockchain system can obtain the transaction request.

[0071] See also Figure 2B In related technologies, a broadcast process can be divided into three stages, sequentially based on execution order: the batch stage (Batch), the pre-confirmation stage (Echo), and the pre-preparation stage (Ready). The multiple blockchain nodes participating in the same broadcast process include two types: broadcast nodes and non-broadcast nodes. A broadcast node is responsible for packaging pending transaction requests (which can be one or more) during the batch stage of the broadcast process and broadcasting them to other participating blockchain nodes for processing. It also handles the broadcast processing of the pending transaction requests. Non-broadcast nodes, on the other hand, only broadcast the pending transaction requests.

[0072] Broadcast processing includes pre-confirmation and pre-preparation. Pre-confirmation occurs during the pre-confirmation phase, while pre-preparation occurs during the pre-preparation phase. Pre-confirmation refers to the process of determining whether to pre-confirm the pending transaction request. A positive pre-confirmation indicates receipt of the pending transaction request. Pre-preparation refers to the process of determining whether to pre-prepare the pending transaction request. A positive pre-preparation indicates receipt of the pending transaction request. During multiple broadcast rounds, the participating blockchain nodes may change between rounds. This means that the participating blockchain nodes may change in each round, the broadcasting node may change, and the pending transaction request may also change.

[0073] Transaction consensus refers to the consensus reached by each node in a blockchain system on the transaction data corresponding to a transaction request. Consensus is typically achieved through a consensus algorithm, with each participating node executing the consensus algorithm to execute the corresponding steps of the consensus process. Optional consensus algorithms include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT).

[0074] Typically, a block height in a blockchain requires one or more consensus rounds to reach agreement among participating nodes. Block height represents the number of blocks connected to the blockchain. It serves as a block identifier, indicating a block's position within the blockchain. For example, the genesis block in a blockchain has a default block height of 0. The first block after the genesis block has a block height of 1 (referred to as block 1). The second block after the genesis block has a block height of 2 (referred to as block 2), and so on.

[0075] For example, let's say the current block of a blockchain has a block height of 300 (referred to as block 300). This means that 300 blocks have already been stacked on top of the genesis block, meaning that the number of blocks in the blockchain from the genesis block to block 300 is 301. The consensus process at a specific block height in a blockchain refers to the process of reaching consensus on the blocks to be added to the blockchain network at that block height. If consensus on the block to be added is successful, the block is added to the blockchain, and the block height of the blockchain is increased by 1. For example, the consensus process at block height 10 in a blockchain refers to the process of reaching consensus on the blocks to be added to the blockchain network at block height 10. If consensus on the block is successful, the block is added to the blockchain, increasing the block height from 10 to 11.

[0076] See also Figure 2CIn the related art, a round of consensus process can be divided into three consensus stages according to the execution order, namely the proposal stage (Pre-prepare), the pre-voting stage (Prepare), and the pre-commitment stage (Commit). The multiple nodes participating in the same round of consensus process include two types: proposal nodes (also called master nodes, the same below) and non-proposal nodes (also called slave nodes, the same below). The so-called proposal node refers to a node elected by multiple nodes participating in the consensus. As a proposal node, the node is responsible for generating a block to be agreed upon in the proposal stage of this round of consensus process, and broadcasting the block to be agreed upon to other nodes participating in the consensus for consensus processing; it is also responsible for consensus processing of the block to be agreed upon. Non-proposal nodes only perform consensus processing on the block to be agreed upon.

[0077] Consensus processing consists of pre-voting and pre-committing. Pre-voting occurs during the pre-voting phase, while pre-committing occurs during the pre-committing phase. Pre-voting involves the process of pre-voting on whether to approve the consensus block. Approval of pre-voting indicates approval for the block to be added to the blockchain. Pre-committing involves the process of pre-committing the consensus block. Approval of pre-committing confirms approval for the block to be added to the blockchain. During multiple rounds of consensus at the same block height, the nodes participating in each round may change. This means that the nodes participating in each round may change, the proposal node may change, and the consensus block may also change.

[0078] Among them, transaction broadcasting and transaction consensus in the relevant technology both involve the broadcasting of messages corresponding to the relevant transactions, which not only causes repeated broadcasting of messages corresponding to the transactions, reducing the efficiency of transaction processing, but also wastes network resources. At the same time, when the network is poor, the failure of broadcasting the messages corresponding to the transactions may lead to failure of transaction broadcasting or transaction consensus, thereby reducing the accuracy of transaction processing. It can be seen that the efficiency and accuracy of transaction processing in the relevant technology are low, and the reliability is poor.

[0079] Therefore, in order to improve the efficiency and accuracy of transaction processing and ensure the reliability of transaction processing, this application provides a transaction processing solution based on blockchain. Figure 3A , Figure 3A is a schematic diagram of an implementation environment involved in this application. The implementation environment primarily includes blockchain nodes 301, 302, and 303, which are capable of communicating with each other. It will be understood that blockchain nodes 301, 302, and 303 are connected via a network, which can include various connection types, such as wireless communication links, wired and fiber optic cables, and the like.

[0080] Exemplarily, any one or more of blockchain node 301, blockchain node 302, and blockchain node 303 may be servers that provide various services; wherein the servers that provide various services include but are not limited to independent physical servers, server clusters or distributed systems composed of multiple physical servers, and cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content distribution networks, and big data and artificial intelligence platforms.

[0081] Exemplarily, any one or more of blockchain node 301, blockchain node 302, and blockchain node 303 can be terminal devices; wherein terminal devices include but are not limited to smart phones, tablets, laptops, computers, intelligent voice interaction devices, smart home appliances, smart wearable devices, aircraft, etc.

[0082] It should be noted that Figure 3A The number of blockchain nodes in the example is only for reference only, and any number of blockchain nodes may be used according to actual needs.

[0083] In one embodiment of the present application, the blockchain-based transaction processing method is executed by any blockchain node (i.e., blockchain node 301, blockchain node 302, or blockchain node 303).

[0084] Exemplarily, any blockchain node receives a transaction request sent by a client, and uses the transaction request as a transaction request to be broadcast, and simultaneously obtains proposal data corresponding to the transaction request to be agreed upon. Then, based on the proposal data and the transaction request to be broadcast, a proposal request is generated, and then the proposal request is sent to other blockchain nodes, so that other blockchain nodes obtain the transaction request to be broadcast from the proposal request, and reach consensus on the transaction request to be agreed upon based on the proposal data in the proposal request.

[0085] For easier understanding, see Figure 3B In the embodiment of the present application, the transaction broadcast and transaction consensus proposal stages are integrated, and the transaction corresponding message only needs to be broadcast once, which improves the efficiency of transaction processing and saves network resources. At the same time, it improves the accuracy of transaction processing, further improves the efficiency of transaction processing, and has high reliability of transaction processing.

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

[0087] The following describes in detail the various implementation details of the technical solutions of the embodiments of the present application:

[0088] See Figure 4 , Figure 4 This is a flowchart of a transaction processing method based on blockchain, which is shown in one embodiment of the present application. The transaction processing method based on blockchain can be executed by any blockchain node. Figure 4 As shown, the blockchain-based transaction processing method includes at least S401 to S404, which are described in detail as follows:

[0089] S401: Receive a transaction request sent by a client, and use the transaction request as a transaction request to be broadcast.

[0090] It is understood that, for ease of distinction, in the embodiments of this application, the blockchain node corresponding to the execution subject of the blockchain-based transaction processing method is referred to as the first blockchain node, and the blockchain node communicating and interacting with it is referred to as the second blockchain node. The first blockchain node can be any blockchain node in the blockchain system, and the second blockchain node is any blockchain node in the blockchain system other than the first blockchain node.

[0091] In the embodiments of this application, the client refers to a software application running on the first blockchain node, through which a user can initiate a transaction request. The transaction request may include information related to the transaction request entered by the user through the client; illustratively, the information related to the transaction request includes, but is not limited to, at least one of the following: transaction content, transaction object, and authentication information (e.g., user identity information).

[0092] In the embodiment of the present application, the first blockchain node receives a transaction request sent by the client, and then can use the transaction request from the client as the transaction request to be broadcast, that is, the first blockchain node obtains the transaction request that needs to be broadcast involving transaction broadcast.

[0093] For example, let the first blockchain node be the blockchain node 301 described in the above embodiment, wherein when a user has a transaction demand, he can send a transaction request TX bc Sent to blockchain node 301, and accordingly, blockchain node 301 receives the transaction request TX sent by the client bc At this time, the transaction request TX received by the blockchain node 301 bc This is the transaction request to be broadcast.

[0094] It is understandable that the number of received transaction requests may be one or more, and in actual applications, it can be flexibly adjusted according to specific application scenarios.

[0095] In one embodiment of the present application, the process of receiving the transaction request sent by the client in S401 may include:

[0096] Receiving multiple trade requests from the same client; or

[0097] Receive transaction requests sent by different clients.

[0098] That is, in an optional embodiment, the first blockchain node can receive multiple transaction requests sent by the same client, or the first blockchain node can receive transaction requests sent by different clients respectively, where the number of transaction requests sent by different clients respectively can be one or more; that is, the first blockchain node can receive multiple transaction requests and use the received multiple transaction requests as transaction requests to be broadcast.

[0099] For example, following the above example, client clint1 sends multiple transaction requests tx bc11 、tx bc12 , and tx bc13 Sent to blockchain node 301, and accordingly, blockchain node 301 receives multiple transaction requests tx from client clint1 bc11 、tx bc12 , and tx bc13 .

[0100] Alternatively, client clint1 sends a transaction request tx bc11 、tx bc12 Sent to blockchain node 301, client clint2 sends transaction request tx bc21 、tx bc22 Sent to blockchain node 301, and accordingly, blockchain node 301 receives the transaction request tx from client clint1 bc11 、tx bc12 , and receives the transaction request tx from client clint2 bc21 、tx bc22 .

[0101] In this way, by implementing the optional embodiment, the first blockchain node can receive multiple transaction requests, providing strong support for the broadcast of batch transactions.

[0102] S402, obtaining proposal data corresponding to the transaction request to be agreed upon.

[0103] In the embodiment of the present application, the first blockchain node can obtain proposal data corresponding to the transaction request to be agreed upon, that is, the first blockchain node obtains proposal data corresponding to the transaction request that requires consensus in the transaction consensus stage. The proposal data can be found in the introduction of the aforementioned embodiment and will not be repeated here.

[0104] For example, assume that the first blockchain node is the blockchain node 301 described in the above embodiment, and the blockchain node 301 obtains the transaction request TX to be agreed upon. cn Corresponding proposal data TX cn-pro .

[0105] It should be clear that the transaction request to be agreed upon and the transaction request to be broadcast in the embodiment of the present application can be the same (for example, TX bc =TX cn ) or different (for example, TX bc ≠TX cn ); In actual applications, the transaction requests awaiting consensus can be flexibly adjusted according to the specific application scenarios.

[0106] It is understandable that the number of transaction requests to be agreed upon can be one or more, and in actual applications, it can be flexibly adjusted according to the specific application scenario.

[0107] S403: Generate a proposal request based on the proposal data and the transaction request to be broadcast.

[0108] In the embodiment of the present application, the first blockchain node obtains the proposal data corresponding to the transaction request to be agreed upon and the transaction request to be broadcast, and then generates a proposal request based on the proposal data corresponding to the transaction request to be agreed upon and the transaction request to be broadcast.

[0109] In the embodiment of the present application, the proposal request is a proposal request for initiating both the transaction broadcast and the transaction consensus proposal stages simultaneously, that is, in the embodiment of the present application, the transaction broadcast and the transaction consensus proposal stages are merged together, which only involves one broadcast of the relevant transaction corresponding message, rather than repeated broadcasts, thereby avoiding repeated broadcasts of the transaction corresponding message, improving the efficiency of transaction processing, saving network resources, and avoiding the phenomenon of failure of transaction broadcast or transaction consensus due to failure of broadcast of the transaction corresponding message, thereby improving the accuracy of transaction processing and increasing the reliability of transaction processing.

[0110] For example, following the above example, blockchain node 301 obtains the transaction request TX to be agreed upon cn Corresponding proposal data TX cn-pro and the transaction request TX to be broadcast bc , then the proposal data TX cn-pro And the transaction request TX to be broadcast bc Package and generate a request for proposal RE pro’ , i.e. Request for Proposal RE pro’ =[TX cn-pro , TX bc ].

[0111] As described in the aforementioned embodiment, if the first blockchain node receives multiple transaction requests and uses the multiple transaction requests as transaction requests to be broadcast (i.e., the transaction requests to be broadcast include multiple), then in one embodiment of the present application, the process of generating a proposal request based on the proposal data and the transaction requests to be broadcast in S403 may include:

[0112] Combine multiple transaction requests to be broadcast to obtain a transaction broadcast group;

[0113] Encapsulate the proposal data and transaction broadcast group to generate a proposal request.

[0114] That is, in an optional embodiment, the first blockchain node combines multiple transaction requests to be broadcast to obtain a transaction broadcast group, and then encapsulates the proposal data and transaction broadcast group corresponding to the transaction request to be consensus to generate a proposal request.

[0115] In this way, by implementing the optional embodiment, the proposal data and the transaction broadcast group containing multiple transaction requests to be broadcast are encapsulated, so that the proposal request can be generated simply and accurately.

[0116] Among them, if the first blockchain node receives multiple transaction requests sent by the same client, in an optional embodiment, the first blockchain node combines the multiple transaction requests to be broadcast corresponding to the client to obtain a transaction broadcast group.

[0117] For example, following the above example, the blockchain node 301 receives multiple transaction requests tx from the client clint1. bc11 、tx bc12 , and tx bc13 ; Then it is a number of transaction requests tx to be broadcasted corresponding to client clint1 bc11 、tx bc12 , and tx bc13 Combine and get the transaction broadcast group TX clint1 , that is, transaction broadcast group TX clint1 ={tx bc11 , tx bc12 , tx bc13}.

[0118] Accordingly, if a transaction broadcast group is obtained, the first blockchain node in an optional embodiment encapsulates the proposal data corresponding to the transaction request to be agreed upon and the transaction broadcast group to generate a proposal request.

[0119] For example, following the above example, the proposal data TX cn-pro and transaction broadcast group TX clint1 Package and generate a request for proposal REpro1 , i.e. Request for Proposal RE pro1 =[TX cn-pro ,{tx bc11 , tx bc12 , tx bc13}].

[0120] Among them, if the first blockchain node receives multiple transaction requests sent by different clients, in an optional embodiment, the first blockchain node combines multiple transaction requests to be broadcast corresponding to the same client to obtain multiple transaction broadcast groups.

[0121] For example, following the above example, blockchain node 301 receives a transaction request tx from client clint1. bc11 、tx bc12 , and receives the transaction request tx from client clint2 bc21 、tx bc22 , then the transaction request tx of client clint1 bc11 、tx bc12 ; Then it is a number of transaction requests tx to be broadcasted corresponding to client clint1 bc11 、tx bc12 Combine and get the transaction broadcast group TX clint1 , that is, transaction broadcast group TX clint1 ={tx bc11 , tx bc12}, and multiple transaction requests tx to be broadcasted corresponding to client clint2 bc21 、tx bc22 Combine and get the transaction broadcast group TX clint2 , that is, transaction broadcast group TX clint2 ={tx bc21 , tx bc22}, thus, we get the transaction broadcast group TX clint1 and transaction broadcast group TX clint2 .

[0122] Accordingly, if multiple transaction broadcast groups are obtained, in an optional embodiment, the first blockchain node encapsulates the proposal data corresponding to the consensus transaction request and the multiple transaction broadcast groups to generate a proposal request.

[0123] For example, following the above example, the proposal data TX cn-pro , transaction broadcast group TX clint1 and transaction broadcast group TX clint2 Package and generate a request for proposal RE pro2 , i.e. Request for Proposal RE pro2 =[TX cn-pro ,{txbc11 , tx bc12}, {tx bc21 , tx bc22}].

[0124] In this way, by implementing the optional embodiment, multiple transaction requests to be broadcasted from various clients are classified and combined, which facilitates the management of the transaction requests to be broadcasted and is applicable to a wide range of scenarios.

[0125] S404: Send the proposal request to the blockchain node, so that the blockchain node obtains the transaction request to be broadcast from the proposal request, and reaches a consensus on the transaction request to be broadcast based on the proposal data in the proposal request.

[0126] In the embodiment of the present application, the first blockchain node generates a proposal request, and then can send the proposal request to the second blockchain node. Accordingly, the second blockchain node receives the proposal request sent by the first blockchain node, and can obtain the transaction request to be broadcast from the proposal request, and can obtain proposal data from the proposal request, so as to reach a consensus on the transaction request to be agreed upon based on the proposal data.

[0127] For example, following the above example, let the first blockchain node be the blockchain node 301 described in the above embodiment, and the second blockchain node be the blockchain node 302 and blockchain node 303 described in the above embodiment. Then blockchain node 301 sends the proposal request RE pro’ Send to blockchain node 302 and blockchain node 303 respectively; accordingly, blockchain node 302 receives the proposal request RE sent by blockchain node 301 pro’ and request for proposals from RE pro’ Get the transaction request TX to be broadcast bc , and from the Request for Proposal RE pro’ Get proposal data TX cn-pro , based on the proposal data TX cn-pro Transaction request TX for consensus cn Reach consensus.

[0128] It can be understood that the second blockchain node obtains the transaction request to be broadcast from the proposal request, and then stores the transaction request to be broadcast in the transaction pool corresponding to the second blockchain node. At the same time, the second blockchain node obtains the proposal data from the proposal request, and enters the proposal stage and the pre-submission stage in sequence based on the proposal data to achieve transaction consensus.

[0129] In one embodiment of the present application, after the process of sending the proposal request to the blockchain node in S404, the following steps may also be included:

[0130] If a consensus result is obtained, indicating that the transaction request to be agreed upon has passed, a block generated based on the transaction execution result corresponding to the transaction request to be agreed upon is obtained;

[0131] Store the block on the blockchain.

[0132] That is, in an optional embodiment, if the first blockchain node obtains a consensus result indicating that the consensus of the transaction request to be agreed upon has been passed, it can obtain a block generated based on the transaction execution results corresponding to multiple transaction requests to be agreed upon. At this time, the block is the block to be put on the chain, and the block to be put on the chain is stored on the blockchain to realize the transaction on the chain.

[0133] For example, continuing with the above example, if we get a transaction request TX for representing the consensus cn If the consensus result is passed, the transaction request TX based on the consensus can be obtained. cn The corresponding transaction execution result TER generates a block, and stores the block on the blockchain.

[0134] Among them, in an optional embodiment, the process of obtaining a block generated based on transaction execution results corresponding to multiple transaction requests to be agreed upon may include: obtaining the transaction execution results obtained by executing the transaction requests to be agreed upon, and generating a block based on the transaction execution results.

[0135] Exemplarily, when there are multiple transaction requests to be agreed upon, the execution order between the multiple transaction requests to be agreed upon can also be obtained, and the multiple transaction requests to be agreed upon are executed based on the execution order between the multiple transaction requests to be agreed upon, thereby obtaining a transaction execution result.

[0136] In this way, by implementing the optional embodiment, after the consensus on the transaction request is passed, the corresponding block is stored on the blockchain, which simply and accurately realizes the transaction on the chain and is applicable to many wide scenarios.

[0137] In the embodiment of the present application, the transaction broadcast and transaction consensus proposal stages are integrated, and the transaction corresponding message only needs to be broadcast once, avoiding the phenomenon of repeated broadcast of the transaction corresponding message, improving the efficiency of transaction processing, and saving network resources. At the same time, it also avoids the phenomenon of failure of transaction broadcast or transaction consensus due to failure of broadcast of the transaction corresponding message, thereby improving the accuracy of transaction processing and further improving the efficiency of transaction processing, that is, the reliability of transaction processing is high.

[0138] In one embodiment of the present application, another blockchain-based transaction processing method is provided, which can be executed by any blockchain node. Figure 5As shown, the blockchain-based transaction processing method may further include S501 after S401, and the blockchain-based transaction processing method may include S502 to S503 and S403 to S404.

[0139] S501 to S503 are described in detail as follows:

[0140] S501: Add the transaction request to be broadcast to the transaction pool.

[0141] In the embodiment of the present application, the first blockchain node receives the transaction request to be broadcast, and then can add the transaction request to be broadcast to the transaction pool.

[0142] For example, continuing the above example, the transaction request TX to be broadcast bc Add to the transaction pool, assuming that the transaction pool stores the transaction request TX bc’ TX bc” , then the transaction request TX to be broadcast bc After being added to the transaction pool, the transaction pool stores the transaction request TX bc’ TX bc” and TX bc .

[0143] S502, obtaining a transaction request to be agreed upon; wherein the transaction request to be agreed upon includes a transaction request to be broadcast and at least one of other transaction requests in the transaction pool, where the other transaction request is a transaction request other than the transaction request to be broadcast.

[0144] In the embodiments of the present application, the transaction requests awaiting consensus that can be obtained by the first blockchain node include, but are not limited to, the transaction request to be broadcast and at least one of other transaction requests in the transaction pool, where the other transaction request is a transaction request other than the transaction request to be broadcast. That is, the transaction requests awaiting consensus include the transaction request to be broadcast and / or other transaction requests in the transaction pool.

[0145] For example, following the above example, the transaction request to be agreed upon includes the transaction request TX to be broadcasted bc , and / or, other transaction requests TX in the transaction pool bc’ TX bc” (Can be other transaction request TX bc’ TX bc” TX bc’ , or TX bc” , or TX bc’ and TX bc” ).

[0146] It is understandable that if the transaction request to be agreed upon is the transaction request to be broadcasted, then the transaction request to be agreed upon and the transaction request to be broadcasted are the same (for example, in the above example, TX bc =TX cn ), and if the transaction request to be agreed upon is other transaction requests in the transaction pool, or the transaction request to be agreed upon is a transaction request to be broadcasted and other transaction requests in the transaction pool, then the transaction request to be agreed upon and the transaction request to be broadcasted are different (for example, in the above example, TX bc ≠TX cn ).

[0147] S503: Generate proposal data corresponding to the transaction request to be agreed upon based on the transaction request to be agreed upon.

[0148] In the embodiment of the present application, the first blockchain node obtains the transaction request to be agreed upon, and then generates proposal data corresponding to the transaction request to be agreed upon based on the transaction request to be agreed upon.

[0149] For example, continuing with the previous example, if the transaction request TX cn Request TX for the transaction to be broadcast bc (ie TX bc =TX cn ), is based on the transaction request TX to be broadcast bc Generate a transaction request TX to be agreed upon cn Corresponding proposal data TX cn-pro .

[0150] If the transaction request TX cn Request TX for other transactions in the transaction pool bc’ , and / or TX bc” (ie TX bc ≠TX cn ), then based on other transaction requests TX bc’ , and / or TX bc” Generate a transaction request TX to be agreed upon cn Corresponding proposal data TX cn-pro .

[0151] If the transaction request TX cn Request TX for the transaction to be broadcast bc and other transaction requests TX in the transaction pool bc’ , and / or TX bc” (ie TX bc ≠TX cn ), then based on the transaction request TX to be broadcast bc and other transaction requests TX bc’ , and / or TX bc”Generate a transaction request TX to be agreed upon cn Corresponding proposal data TX cn-pro .

[0152] It should be noted that Figure 5 For detailed description of S401, S403 to S404, please refer to Figure 4 S401, S403 to S404 shown are not described in detail here.

[0153] In the embodiments of the present application, the transaction requests to be agreed upon include various situations, which may be the same as or different from the transaction requests to be broadcast. Therefore, transaction broadcasting and transaction consensus are highly flexible and applicable to a wide range of scenarios.

[0154] In one embodiment of the present application, another blockchain-based transaction processing method is provided, which can be executed by any blockchain node. Figure 6 As shown, the blockchain-based transaction processing method may include S601 to S603, S501 to S502, S401, and S403 to S404.

[0155] In the embodiment of the present application, there are multiple transaction requests to be agreed upon.

[0156] For example, following the above example, the transaction request to be agreed upon is the transaction request to be broadcast, where the transaction request to be broadcast includes tx bc11 、tx bc12 , and tx bc13 , that is, multiple transaction requests to be agreed upon are tx bc11 、tx bc12 , and tx bc13 .

[0157] Alternatively, the transaction request to be agreed upon is also the transaction request to be broadcast, where the transaction request to be broadcast includes tx bc11 、tx bc12 、tx bc21 , and tx bc22 , that is, multiple transaction requests to be agreed upon are tx bc11 、tx bc12 、tx bc21 , and tx bc22 .

[0158] S601 to S603 are described in detail as follows:

[0159] S601, combining multiple transaction requests to be agreed upon to obtain a transaction consensus group.

[0160] In the embodiment of the present application, the first blockchain node obtains multiple transaction requests to be agreed upon, and then can combine the multiple transaction requests to be agreed upon to obtain a transaction consensus group.

[0161] For example, following the above example, multiple transaction requests to be agreed upon are tx bc11 、tx bc12 , and tx bc13 , then it is a transaction request tx for multiple transactions to be agreed upon bc11 、tx bc12 , and tx bc13 Combine and get the transaction consensus group TX cn1 , that is, the transaction consensus group TX cn1 ={tx bc11 , tx bc12 , tx bc13}.

[0162] Alternatively, multiple transaction requests to be agreed upon are tx bc11 、tx bc12 、tx bc21 , and tx bc22 , then it is a transaction request tx for multiple transactions to be agreed upon bc11 、tx bc12 、tx bc21 , and tx bc22 Combine and get the transaction consensus group TX cn2 , that is, the transaction consensus group TX cn2 ={tx bc11 , tx bc12 , tx bc21 , tx bc22}.

[0163] S602: Perform a signature operation on the transaction consensus group to obtain signature data corresponding to the transaction consensus group.

[0164] In the embodiment of the present application, the first blockchain node obtains the transaction consensus group, and then can perform a signing operation on the transaction consensus group to obtain signature data corresponding to the transaction consensus group.

[0165] In the embodiment of the present application, the signature data is used by the blockchain node to verify the signature data, so as to complete the consensus of the transaction consensus group; in other words, the consensus of the transaction consensus group at least includes the signature verification of the transaction consensus group.

[0166] For example, following the above example, for the transaction consensus group TX cn1 Perform the signature operation to obtain the transaction consensus group TX cn1 Corresponding signature data TX cn1-sig , so that based on the transaction consensus group TXcn1 Corresponding signature data TX cn1-sig Perform verification operations.

[0167] Or, for the transaction consensus group TX cn2 Perform the signature operation to obtain the transaction consensus group TX cn2 Corresponding signature data TX cn2-sig , so that based on the transaction consensus group TX cn2 Corresponding signature data TX cn2-sig Perform verification operations.

[0168] S603: Generate proposal data corresponding to the transaction consensus group based on the signature data and the transaction consensus group.

[0169] In the embodiment of the present application, the first blockchain node obtains the transaction consensus group and the signature data corresponding to the transaction consensus group, and then can generate proposal data corresponding to the transaction consensus group based on the transaction consensus group and the signature data corresponding to the transaction consensus group.

[0170] For example, if we continue with the above example, we get the transaction consensus group TX cn1 and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig , then it is based on the transaction consensus group TX cn1 and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig Generate transaction consensus group TX cn1 Corresponding proposal data TX cn1-pro , that is, proposal data TX cn1-pro =[TX cn1 , TX cn1-sig ].

[0171] Or, if the transaction consensus group TX is obtained cn2 and transaction consensus group TX cn2 Corresponding signature data TX cn2-sig , then it is based on the transaction consensus group TX cn2 and transaction consensus group TX cn2 Corresponding signature data TX cn2-sig Generate transaction consensus group TX cn2 Corresponding proposal data TX cn2-pro , that is, proposal data TX cn2-pro =[TX cn2 , TX cn2-sig ].

[0172] In one embodiment of the present application, the process of generating proposal data corresponding to the transaction consensus group based on the signature data and the transaction consensus group in S603 may include:

[0173] Obtain the transaction execution order among multiple transaction requests to be agreed upon in the transaction consensus group;

[0174] Based on the transaction execution order and signature data, the proposal data corresponding to the transaction consensus group is generated; among them, the transaction execution order is used by the blockchain node to verify the transaction execution order to complete the consensus of the transaction consensus group.

[0175] That is, in the optional embodiment, the first blockchain node obtains the transaction execution order between multiple transaction requests to be agreed upon in the transaction consensus group, and then generates proposal data corresponding to the transaction consensus group based on the transaction execution order between the multiple transaction requests to be agreed upon in the transaction consensus group and the signature data corresponding to the transaction consensus group.

[0176] Among them, in the optional embodiment, the transaction execution order is used by the blockchain node to verify the transaction execution order, so as to complete the consensus of the transaction consensus group; in other words, the consensus of the transaction consensus group at least also includes the consensus operation on the transaction execution order between multiple transaction requests to be agreed upon in the transaction consensus group.

[0177] For example, if we continue with the above example, we get the transaction consensus group TX cn1 and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig , then you also need to obtain the transaction consensus group TX cn1 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 , and tx bc13 The order of transaction execution between them. At the same time, the transaction consensus group TX cn1 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 , and tx bc13 The transaction execution order between tx bc11 ->tx bc12 ->tx bc13 , then it is based on the transaction execution order tx bc11 ->tx bc12 ->tx bc13 and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig , generate transaction consensus group TX cn1 Corresponding proposal data TX cn1-pro , that is, proposal data TX cn1-pro =[tx bc11 ->tx bc12 ->tx bc13 , TX cn1-sig ], so that based on the transaction consensus group TXcn1 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 , and tx bc13 The order of transaction execution between tx bc11 ->tx bc12 ->tx bc13 Perform consensus operations.

[0178] For example, it is also possible to use the transaction consensus group TX cn1 , transaction execution order tx bc11 ->tx bc12 ->tx bc13 and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig Generate transaction consensus group TX cn1 Corresponding proposal data TX cn1-pro , that is, proposal data TX cn1-pro =[tx bc11 ->tx bc12 ->tx bc13 , TX cn1 , TX cn1-sig ].

[0179] Or, if the transaction consensus group TX is obtained cn2 and transaction consensus group TX cn2 Corresponding signature data TX cn2-sig , then you also need to obtain the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 The order of transaction execution between them. At the same time, the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 The transaction execution order between tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 , then it is based on the transaction execution order tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 and transaction consensus group TX cn2 Corresponding signature data TX cn2-sig , generate transaction consensus group TX cn2 Corresponding proposal data TX cn2-pro , that is, proposal data TXcn2-pro =[tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 , TX cn2-sig ], so that based on the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 The order of transaction execution between tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 Perform consensus operations.

[0180] For example, it is also possible to use the transaction consensus group TX cn2 , transaction execution order tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 and transaction consensus group TX cn2 Corresponding signature data TX cn2-sig Generate transaction consensus group TX cn2 Corresponding proposal data TX cn2-pro , that is, proposal data TX cn2-pro =[tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 , TX cn2 , TX cn2-sig ].

[0181] In this way, through the optional embodiment of the embodiment, based on the transaction execution order between multiple transaction requests to be agreed upon in the transaction consensus group, the proposal data corresponding to the transaction consensus group can be generated simply and accurately, thereby achieving the consensus of the transaction consensus group, which is applicable to many wide scenarios.

[0182] In one embodiment of the present application, the blockchain system includes multiple blockchain nodes; for example, as described in the aforementioned embodiment, the multiple blockchain nodes are blockchain node 301, blockchain node 302, and blockchain node 303.

[0183] If the blockchain node includes multiple nodes, then in one embodiment of the present application, after the process of sending the proposal request to the blockchain node in S404, the following steps may also be included:

[0184] Determine a first target blockchain node from multiple blockchain nodes that passes transaction execution order verification;

[0185] If the number of the first target blockchain nodes reaches a first preset number threshold, it is determined that the consensus of the transaction consensus group is passed.

[0186] Among them, in the optional embodiment, the first target blockchain node refers to a blockchain node among multiple blockchain nodes that has passed the transaction execution order verification between multiple transaction requests to be agreed upon in the transaction consensus group.

[0187] For example, take the proposal data TX in the above example cn2-pro For example, if the proposal data TX cn2-pro =[tx bc11 ->tx bc12 ->tx bc13 , TX cn2-sig ], then the transaction consensus group TX is determined from blockchain node 301, blockchain node 302, and blockchain node 303. cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 The order of transaction execution between tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 The first blockchain node that passed the verification.

[0188] Among them, in an optional embodiment, the process of determining the first target blockchain node that has passed the transaction execution order verification from multiple blockchain nodes may include: receiving response information sent by each blockchain node to represent the success of the transaction execution order verification; determining the blockchain node corresponding to the response information that has passed the transaction execution order verification from multiple blockchain nodes, and using the determined blockchain node as the first target blockchain node.

[0189] That is, in an optional embodiment, the first blockchain node receives response information sent by each blockchain node for representing that the transaction execution order between multiple transaction requests to be agreed upon in the transaction consensus group has been verified. Then, the blockchain node corresponding to the response information for representing that the transaction execution order between multiple transaction requests to be agreed upon in the transaction consensus group has been verified is determined from multiple blockchain nodes. At this time, the blockchain node determined is the first target blockchain node.

[0190] For example, take the above proposal data TX cn2-pro For example, assume that blockchain node 301 receives a message sent by blockchain node 302 and blockchain node 303 to represent the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus txbc11 、tx bc12 、tx bc21 , and tx bc22 The order of transaction execution between tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 The blockchain node 301 also sends a response message to the blockchain node 302 and the blockchain node 303 to represent the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 The order of transaction execution between tx bc11 ->tx bc12 ->tx bc21 ->tx bc22 Verification passed response information. At this time, blockchain node 301, blockchain node 302, and blockchain node 303 are all first target blockchain nodes.

[0191] It is understandable that in an optional embodiment, a first target blockchain node that has passed the transaction execution order verification is determined from multiple blockchain nodes, and then whether the consensus of the transaction consensus group has been passed can be determined based on the number of the first target blockchain nodes.

[0192] In the optional embodiment, determining whether the consensus of the transaction consensus group is passed based on the number of nodes in the first target blockchain may include two situations:

[0193] In case 1, if the number of the first target blockchain nodes reaches the first preset number threshold, it indicates that the consensus on the transaction execution order between the multiple transaction requests to be agreed upon in the current transaction consensus group has been passed, and at this time, it is determined that the consensus on the transaction consensus group has been passed.

[0194] Case 2: If the number of the first target blockchain nodes does not reach the first preset number threshold, it indicates that the consensus on the transaction execution order between the multiple transaction requests to be agreed upon in the current transaction consensus group has not been passed. At this time, it is determined that the consensus on the transaction consensus group has not been passed.

[0195] It should be clear that, in actual applications, the first preset quantity threshold can be flexibly adjusted according to specific application scenarios.

[0196] Among them, in an optional embodiment, after determining that the consensus of the transaction consensus group has been passed, the process may also include: obtaining a block generated based on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group; and storing the block on the blockchain.

[0197] That is, in an optional embodiment, if the consensus on the transaction execution order between multiple transaction requests to be agreed upon in the transaction consensus group is passed, which indicates that the transaction consensus is passed at this time, then a block generated based on the transaction execution results corresponding to the multiple transaction requests to be agreed upon in the transaction consensus group can be obtained. At this time, the block is the block to be on the chain, and the block to be on the chain is stored on the blockchain to realize the transaction on the chain.

[0198] Among them, in an optional embodiment, the process of obtaining a block generated based on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group may include: obtaining the transaction execution order between the multiple transaction requests to be agreed upon in the transaction consensus group; executing the multiple transaction requests to be agreed upon in the transaction consensus group based on the transaction execution order between the multiple transaction requests to be agreed upon in the transaction consensus group to obtain the transaction execution results; and generating a block based on the transaction execution results.

[0199] In this way, by implementing the optional embodiment, after consensus is reached on the transaction execution order among multiple transaction requests to be agreed upon in the transaction consensus group, the corresponding blocks are stored on the blockchain, which simply and accurately implements the transaction chain, and is applicable to a wide range of scenarios.

[0200] It is understandable that after consensus is reached on the transaction execution order among multiple transaction requests to be agreed upon in the transaction consensus group, the transaction execution results obtained will usually also be reached by consensus; therefore, in order to save transaction consensus time and improve transaction consensus efficiency, in an optional embodiment, the corresponding blocks are stored on the blockchain after consensus is reached on the transaction execution order.

[0201] In one embodiment of the present application, the process of generating proposal data corresponding to the transaction consensus group based on the signature data and the transaction consensus group in S603 may include:

[0202] Execute multiple transaction requests awaiting consensus in the transaction consensus group and obtain transaction execution results;

[0203] Based on the transaction execution results and signature data, proposal data corresponding to the transaction consensus group is generated; among them, the transaction execution results are used by blockchain nodes to verify the transaction execution results to complete the consensus of the transaction consensus group.

[0204] That is, in the optional embodiment, the first blockchain node executes multiple transaction requests to be agreed upon in the transaction consensus group, obtains the transaction execution result, and then generates proposal data corresponding to the transaction consensus group based on the transaction execution results corresponding to the multiple transaction requests to be agreed upon in the transaction consensus group and the signature data corresponding to the transaction consensus group.

[0205] Among them, in the optional embodiment, the transaction execution result is used by the blockchain node to verify the transaction execution result, so as to complete the consensus of the transaction consensus group; in other words, the consensus of the transaction consensus group at least also includes consensus operations on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group.

[0206] For example, if we continue with the above example, we get the transaction consensus group TX cn1 and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig , then you also need to obtain the transaction consensus group TX cn1 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 , and tx bc13 The corresponding transaction execution results. At the same time, the transaction consensus group TX cn1 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 , and tx bc13 The corresponding transaction execution result is TX cn1-res , then it is based on the transaction execution result TX cn1-res and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig , generate transaction consensus group TX cn1 Corresponding proposal data TX cn1-pro , that is, proposal data TX cn1-pro =[TX cn1-res , TX cn1-sig ], so that based on the transaction consensus group TX cn1 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 , and tx bc13 Corresponding transaction execution result TX cn1-res Perform consensus operations.

[0207] For example, it is also possible to use the transaction consensus group TX cn1 , transaction execution result TX cn1-res and transaction consensus group TX cn1 Corresponding signature data TX cn1-sig Generate transaction consensus group TX cn1 Corresponding proposal data TX cn1-pro , that is, proposal data TX cn1-pro =[TX cn1-res , TX cn1 , TX cn1-sig ].

[0208] Or, if the transaction consensus group TX is obtained cn2 and transaction consensus group TXcn2 Corresponding signature data TX cn2-sig , then you also need to obtain the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 The corresponding transaction execution results. At the same time, the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 The corresponding transaction execution result is TX cn2-res , then it is based on the transaction execution result TX cn2-res and transaction consensus group TX cn2 Corresponding signature data TX cn2-sig , generate transaction consensus group TX cn2 Corresponding proposal data TX cn2-pro , that is, proposal data TX cn2-pro =[TX cn2-res , TX cn2-sig ], so that based on the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 Corresponding transaction execution result TX cn2-res Perform consensus operations.

[0209] For example, it is also possible to use the transaction consensus group TX cn2 , transaction execution result TX cn2-res and transaction consensus group TX cn2 Corresponding signature data TX cn2-sig Generate transaction consensus group TX cn2 Corresponding proposal data TX cn2-pro , that is, proposal data TX cn2-pro =[TX cn2-res , TX cn2 , TX cn2-sig ].

[0210] In this way, through the optional embodiment of the embodiment, based on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group, the proposal data corresponding to the transaction consensus group can be generated simply and accurately, thereby achieving the consensus of the transaction consensus group, which is applicable to many wide scenarios.

[0211] In one embodiment of the present application, the blockchain system includes multiple blockchain nodes; for example, as described in the aforementioned embodiment, the multiple blockchain nodes are blockchain node 301, blockchain node 302, and blockchain node 303.

[0212] If the blockchain node includes multiple nodes, then in one embodiment of the present application, after the process of sending the proposal request to the blockchain node in S404, the following steps may also be included:

[0213] Determine a second target blockchain node from the plurality of blockchain nodes that has verified the transaction execution result;

[0214] If the number of the second target blockchain nodes reaches the second preset number threshold, it is determined that the consensus of the transaction consensus group is passed.

[0215] Among them, in the optional embodiment, the second target blockchain node refers to a blockchain node among multiple blockchain nodes that has passed the verification of the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group.

[0216] For example, take the proposal data TX in the above example cn2-pro For example, if the proposal data TX cn2-pro =[TX cn2-res , TX cn2-sig ], then the transaction consensus group TX is determined from blockchain node 301, blockchain node 302, and blockchain node 303. cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 Corresponding transaction execution result TX cn2-res The second blockchain node that passed the verification.

[0217] Among them, in an optional embodiment, the process of determining a second target blockchain node that has passed the verification of the transaction execution result from multiple blockchain nodes may include: receiving response information sent by each blockchain node to represent the verification of the transaction execution result; determining the blockchain node corresponding to the response information that has passed the verification of the transaction execution result from multiple blockchain nodes, and using the determined blockchain node as the second target blockchain node.

[0218] That is, in an optional embodiment, the first blockchain node receives response information sent by each blockchain node for representing the verification of the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group, and then determines the blockchain node corresponding to the response information for representing the verification of the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group from multiple blockchain nodes. At this time, the determined blockchain node is the second target blockchain node.

[0219] For example, take the above proposal data TX cn2-pro For example, assume that blockchain node 301 receives a message sent by blockchain node 302 and blockchain node 303 to represent the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 Corresponding transaction execution result TX cn2-res The blockchain node 301 also sends a response message to the blockchain node 302 and the blockchain node 303 to represent the transaction consensus group TX cn2 Multiple transaction requests awaiting consensus tx bc11 、tx bc12 、tx bc21 , and tx bc22 Corresponding transaction execution result TX cn2-res Verification passed response information. At this time, blockchain node 301, blockchain node 302, and blockchain node 303 are all second target blockchain nodes.

[0220] It is understandable that in an optional embodiment, a second target blockchain node that has passed the verification of the transaction execution result is determined from multiple blockchain nodes, and then whether the consensus of the transaction consensus group has been passed can be determined based on the number of second target blockchain nodes.

[0221] In the optional embodiment, determining whether the consensus of the transaction consensus group is passed based on the number of the second target blockchain nodes may include two situations:

[0222] In case 1, if the number of the second target blockchain nodes reaches the second preset number threshold, it indicates that the consensus on the transaction execution results corresponding to the multiple transaction requests to be agreed upon in the current transaction consensus group has been passed, and at this time, it is determined that the consensus on the transaction consensus group has been passed.

[0223] Case 2: If the number of the second target blockchain nodes does not reach the second preset number threshold, it indicates that the consensus on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the current transaction consensus group has not been passed. At this time, it is determined that the consensus on the transaction consensus group has not been passed.

[0224] It should be clear that in actual applications, the second preset quantity threshold can be flexibly adjusted according to the specific application scenario, wherein the second preset quantity threshold can be the same as or different from the first preset quantity threshold in the aforementioned embodiment.

[0225] Among them, in an optional embodiment, after determining that the consensus of the transaction consensus group has been passed, the process may also include: obtaining a block generated based on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group; and storing the block on the blockchain.

[0226] That is, in an optional embodiment, if the consensus on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group is passed, which indicates that the transaction consensus is passed at this time, then a block generated based on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group can be obtained. At this time, the block is the block to be on the chain, and the block to be on the chain is stored on the blockchain to realize the transaction on the chain.

[0227] Among them, in an optional embodiment, the process of obtaining a block generated based on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group may include: obtaining the transaction execution order between the multiple transaction requests to be agreed upon in the transaction consensus group; executing the multiple transaction requests to be agreed upon in the transaction consensus group based on the transaction execution order between the multiple transaction requests to be agreed upon in the transaction consensus group to obtain the transaction execution results; and generating a block based on the transaction execution results.

[0228] In this way, by implementing the optional embodiment, after consensus is reached on the transaction execution results corresponding to multiple transaction requests to be agreed upon in the transaction consensus group, the corresponding blocks are stored on the blockchain, which simply and accurately realizes the transaction chain, and is applicable to a wide range of scenarios.

[0229] It should be noted that Figure 6 For detailed description of S501 to S502, please refer to Figure 5 As shown in S501 to S502, Figure 6 For detailed description of S401, S403 to S404, please refer to Figure 4 S401, S403 to S404 shown are not described in detail here.

[0230] In the embodiment of the present application, based on the transaction consensus group and the signature data corresponding to the transaction consensus group, the proposal data corresponding to the transaction consensus group can be generated simply and accurately, thereby achieving the consensus of the transaction consensus group, which is applicable to a wide range of scenarios.

[0231] In one embodiment of the present application, another blockchain-based transaction processing method is provided, which can be executed by any blockchain node. Figure 7 As shown, the blockchain-based transaction processing method may further include S701 to S703 after S401.

[0232] S701 to S703 are described in detail as follows:

[0233] S701: Extract transaction requests received within a preset time period before the current time point from a transaction pool.

[0234] In the embodiment of the present application, the first blockchain node can extract the transaction requests received within the latest historical time period from the transaction pool regularly / irregularly, where the end value of the time interval corresponding to the latest historical time period is the current time point.

[0235] It is understandable that the number of extracted transaction requests may be one or more, and in actual applications, it can be flexibly adjusted according to specific application scenarios.

[0236] S702, obtaining broadcast credential information corresponding to the extracted transaction request; wherein the broadcast credential information is generated based on voting information corresponding to the extracted transaction request, and the voting information is generated in response to the reception status of the extracted transaction request when the extracted transaction request is broadcast.

[0237] In the embodiment of the present application, the first blockchain node extracts the transaction request within the latest historical time period, and then can obtain the broadcast credential information corresponding to the extracted transaction request.

[0238] In the embodiments of this application, the broadcast credential information corresponding to a transaction request, also known as a quorum certificate (QC), is generated based on the voting information corresponding to the transaction request. The voting information is generated in response to the reception of the transaction request when the transaction request is broadcast. It is understood that, as described in the previous embodiments, the broadcast credential information includes 2f+1 pieces of ready vote information.

[0239] S703: Send the broadcast credential information to the blockchain node, so that the blockchain node detects the storage status corresponding to the extracted transaction request based on the broadcast credential information.

[0240] In the embodiment of the present application, the first blockchain node obtains the broadcast credential information corresponding to the transaction request and can then send the broadcast credential information corresponding to the transaction request to the second blockchain node. Accordingly, the second blockchain node receives the broadcast credential information sent by the first blockchain node and can detect the storage status of the extracted transaction request based on the broadcast credential information. In other words, the second blockchain node detects the storage integrity of the transaction request extracted by the first blockchain node on the second blockchain node based on the broadcast credential information, specifically detecting whether the transaction request extracted by the first blockchain node on the second blockchain node is missing or out of sync.

[0241] If the extracted transaction request includes multiple transactions (i.e., the broadcast credential information corresponding to each transaction request is obtained), then in one embodiment of the present application, the process of sending the broadcast credential information to the blockchain node in S703 may include:

[0242] Combining multiple broadcast credential information to obtain a broadcast credential information group;

[0243] Send the broadcast credential information group to the blockchain node.

[0244] That is, in an optional embodiment, when the first blockchain node obtains multiple broadcast credential information, the multiple broadcast credential information are combined to obtain a broadcast credential information group, and then the broadcast credential information group is sent to the second blockchain node. Accordingly, the second blockchain node receives the broadcast credential information group sent by the first blockchain node, and can detect the storage status corresponding to the extracted transaction request based on the broadcast credential information group.

[0245] For example, let blockchain node 301 extract the transaction request within the latest historical time period from the transaction pool as TX cn1 ={tx cn11 , tx cn12 , tx cn13} and TX cn2 ={tx bc11 , tx bc12 , tx bc21 , tx bc22}, and obtain the transaction consensus group TX cn1 The corresponding broadcast certificate information qc1 and the transaction consensus group TX cn2The corresponding broadcast credential information qc2. Then the broadcast credential information qc1 and the broadcast credential information qc2 can be combined to obtain the broadcast credential information group QC, that is, QC = {qc1, qc2}, and then the broadcast credential information group QC is sent to the blockchain node 302 and the blockchain node 303 respectively, so that the blockchain node 302 and the blockchain node 303 can respectively check the TX based on the broadcast credential information group QC. cn1 and TX cn2 The corresponding storage situation is detected. Specifically, for blockchain node 302, it is to detect whether the transaction pool corresponding to blockchain node 302 stores TX cn1 and TX cn2 For blockchain node 303, it is to detect whether the transaction pool corresponding to blockchain node 303 stores TX cn1 and TX cn2 .

[0246] In this way, by implementing the optional embodiment, multiple broadcast credential information is combined and then sent, which ensures the accuracy of sending and thus improves the accuracy of detection.

[0247] In one embodiment of the present application, after the process of sending the broadcast credential information to the blockchain node in S703, the following steps may also be included:

[0248] Receiving a request for a missing transaction request from a blockchain node, wherein the request is generated by the blockchain node after detecting that the transaction request is missing based on the broadcast credential information;

[0249] The missing transaction request is sent to the blockchain node so that the blockchain node performs synchronization operations on the missing transaction request.

[0250] That is, in an optional embodiment, after the second blockchain node detects that a transaction request is missing based on the broadcast credential information, it can generate a retrieval request corresponding to the missing transaction request, and then send the retrieval request to the first blockchain node. In response, the first blockchain node receives the retrieval request sent by the second blockchain node and obtains the missing transaction request of the second blockchain node based on the retrieval request. The first blockchain node then sends the acquired missing transaction request of the second blockchain node to the second blockchain node. In response, the second blockchain node receives the missing transaction request sent by the first blockchain node and performs a synchronization operation on the missing transaction request. Exemplarily, the synchronization operation can be storing the received missing transaction request in the transaction pool corresponding to the second blockchain node.

[0251] For example, following the above example, the blockchain node 302 detects that there is a missing transaction request tx cn12, blockchain node 303 detects that there is no missing transaction request. Then blockchain node 302 can send a transaction request tx to blockchain node 301 cn12 Accordingly, the blockchain node 301 receives the transaction request tx sent by the blockchain node 302. cn12 Get the request and send the transaction request tx cn12 Send to blockchain node 302, so that blockchain node 302 can receive the transaction request tx based on the received transaction request tx cn12 Perform synchronous operations.

[0252] It is understandable that the missing transaction request in the optional embodiment may be due to reception failure caused by poor network quality, or other reasons. In actual application, it can be flexibly adjusted according to the specific application scenario.

[0253] In this way, by implementing the optional embodiment, the missing transaction requests can be synchronized, thereby providing strong support for the smooth transaction consensus.

[0254] It should be noted that Figure 7 For detailed description of S401 to S404, please refer to Figure 4 S401 to S404 shown are not described in detail here.

[0255] In the embodiment of the present application, based on the broadcast credential information corresponding to the transaction requests within the latest historical time period, the storage status of the transaction requests within the latest historical time period can be detected simply and accurately, thereby avoiding the phenomenon of transaction consensus failure due to missing / non-synchronization of transaction requests and improving the accuracy of transaction consensus.

[0256] The following is a detailed description of a specific scenario in an embodiment of the present application:

[0257] See also Figure 8 , Figure 8 This is a flowchart of a transaction processing method based on blockchain, as shown in one embodiment of the present application. Figure 8 As shown, the blockchain-based transaction processing method includes at least S801 to S808, which are described in detail as follows:

[0258] S801: Receive multiple transaction requests to be broadcast, and add the multiple transaction requests to be broadcast to a transaction pool.

[0259] In the embodiment of the present application, multiple transaction requests to be broadcast may come from different clients. After receiving multiple transaction requests to be broadcast, the multiple transaction requests to be broadcast are added to the transaction pool to update the transaction pool.

[0260] S802: Combine multiple transaction requests to be broadcast according to node types to obtain multiple transaction broadcast groups.

[0261] In the embodiment of the present application, the client can be installed on different blockchain nodes, so the multiple transaction requests to be broadcast received can be combined according to the node type to obtain multiple transaction broadcast groups.

[0262] S803: The multiple transaction requests to be broadcasted are used as multiple transaction requests to be agreed upon.

[0263] In the embodiment of the present application, the transaction request to be agreed upon and the transaction request to be broadcast are the same. In other embodiments, the transaction request to be agreed upon and the transaction request to be broadcast may be different.

[0264] S804: Perform a signature operation on the multiple transaction requests to be agreed upon, and obtain signature data of the multiple transaction requests to be agreed upon.

[0265] In the embodiment of the present application, a plurality of transaction requests to be agreed upon are obtained, and then a signing operation can be performed on the plurality of transaction requests to be agreed upon, thereby obtaining signature data corresponding to the plurality of transaction requests to be agreed upon.

[0266] S805: Obtain the transaction execution order among multiple transaction requests to be agreed upon.

[0267] In the embodiment of the present application, since there are multiple transaction requests to be agreed upon, the transaction execution order between the multiple transaction requests to be agreed upon can be obtained.

[0268] S806: Generate proposal data corresponding to the multiple transaction requests to be agreed upon based on the signature data corresponding to the multiple transaction requests to be agreed upon and the transaction execution order between the multiple transaction requests to be agreed upon.

[0269] In the embodiment of the present application, signature data corresponding to multiple transaction requests to be agreed upon and the transaction execution order between the multiple transaction requests to be agreed upon are obtained. Then, based on the signature data corresponding to the multiple transaction requests to be agreed upon and the transaction execution order between the multiple transaction requests to be agreed upon, proposal data corresponding to the multiple transaction requests to be agreed upon can be generated.

[0270] S807: Encapsulate proposal data corresponding to multiple transaction broadcast groups and multiple transaction requests to be agreed upon, and generate proposal requests.

[0271] In the embodiment of the present application, multiple transaction broadcast groups and proposal data corresponding to multiple transaction requests to be agreed upon are obtained, and then proposal requests can be generated based on the encapsulation of the proposal data corresponding to the multiple transaction broadcast groups and multiple transaction requests to be agreed upon.

[0272] S808, sending the proposal request to the blockchain node, so that the blockchain node obtains proposal data corresponding to multiple transaction broadcast groups and multiple transaction requests to be agreed upon from the proposal request, and reaches consensus on the multiple transaction requests to be agreed upon based on the proposal data corresponding to the multiple transaction requests to be agreed upon.

[0273] In the embodiment of the present application, a proposal request is generated and can be sent to a blockchain node, so that the blockchain node can obtain proposal data corresponding to multiple transaction broadcast groups and multiple transaction requests to be agreed upon from the proposal request, and perform storage operations on the multiple transaction broadcast groups. At the same time, consensus is reached on the multiple transaction requests to be agreed upon based on the proposal data corresponding to the multiple transaction requests to be agreed upon.

[0274] For easier understanding, see Figure 9 ,in Figure 9 In the above code, b represents the transaction consensus group (also called transaction batch or transaction shard), which may include multiple transaction requests to be agreed upon, and s represents the proposal data of the transaction consensus group, which is used to distinguish.

[0275] like Figure 9 As shown in the figure, during the 10-block consensus process, each blockchain node will broadcast the transaction request received from the client to other blockchain nodes. At the same time, when broadcasting the transaction request, it will also broadcast the proposal data of the transaction request. In this way, each blockchain node can receive the transaction request broadcasted by other blockchain nodes and the proposal data of the transaction request (for example, at height 2, it includes the received s and the qc corresponding to the transaction request). After that, it can pre-vote on the transaction request, enter the pre-voting stage, and then enter the pre-commit stage.

[0276] As a result, the transaction broadcast and transaction consensus proposal stages are integrated, which does not involve repeated broadcasting of transaction corresponding messages, improves the efficiency and accuracy of transaction processing, and saves network resources.

[0277] In one embodiment of the present application, the blockchain node detects multiple transaction requests to be broadcast / multiple transaction requests to be agreed upon through a checkpoint mechanism to avoid the phenomenon of missing / non-synchronization of transaction requests due to network or other reasons.

[0278] For easier understanding, see Figure 10 , in order to use the checkpoint mechanism to detect transaction requests at preset intervals, where QC represents the broadcast credential information group. Multiple QCs can be broadcast at the same time. In actual applications, it can be flexibly adjusted according to specific application scenarios.

[0279] Next, we introduce several detection scenarios.

[0280] Detection scenario 1, see Figure 11 , each blockchain node has no missing transaction consensus group.

[0281] like Figure 11 As shown in the figure, through the checkpoint message aggregation of each blockchain node, each blockchain node can perceive that all blockchain nodes have received the transaction consensus group in a certain high-degree consensus and received the votes of the other 2f+1 blockchain nodes. Therefore, each blockchain node can execute these four transaction consensus groups to complete the block consensus.

[0282] Detection scenario 2, see Figure 12 , a single blockchain node has a missing transaction consensus group.

[0283] like Figure 12 As shown, blockchain node 4 detects that it is missing a transaction consensus group at a certain height (i.e., b', b", and b'". At this time, blockchain node 4 can request the missing transaction consensus group from the corresponding blockchain node. After blockchain node 4 receives the missing transaction consensus group, it can execute the transaction consensus group to complete the block consensus.

[0284] Detection scenario 3, see Figure 13 , half of the blockchain nodes have missing transaction consensus groups.

[0285] like Figure 13 As shown, blockchain node 1 and blockchain node 2 are located in the same network, wherein blockchain node 1 and blockchain node 2 both detect that they are missing the transaction consensus group of blockchain node 4 (i.e., b""); blockchain node 3 and blockchain node 4 are located in the same network, wherein blockchain node 3 and blockchain node 4 both detect that they are missing the transaction consensus group of blockchain node 1 (i.e., b').

[0286] Because f+1 blockchain nodes have received the missing transaction consensus group, meaning at least one honest blockchain node has received the transaction consensus group, blockchain node 3 can now request the missing transaction consensus group from blockchain node 1. If blockchain node 1 fails to send the missing transaction consensus group to blockchain node 3 in a timely manner, blockchain node 3 can also request the missing transaction consensus group from blockchain node 2. Similarly, the process of obtaining the missing transaction consensus group for other blockchain nodes is similar, and so on, thus completing the block consensus.

[0287] Detection scenario 4, see Figure 14 , multiple blockchain nodes (more than half of the blockchain nodes) have missing transaction consensus groups.

[0288] like Figure 14 As shown, blockchain node 2, blockchain node 3, and blockchain node 4 all detect that they are missing the transaction consensus group (i.e., b') of blockchain node 1. At this time, they cannot be sure whether blockchain node 1 is an honest blockchain node. Therefore, blockchain node 2, blockchain node 3, and blockchain node 4 will not request the missing transaction consensus group from blockchain node 1.

[0289] It can be understood that blockchain node 1 can request the corresponding blockchain node (such as blockchain node 2, blockchain node 3, or blockchain node 4) for the transaction consensus group (i.e., b") that it is missing. The four blockchain nodes simultaneously execute and submit the three transaction consensus groups corresponding to blockchain node 2, blockchain node 3, and blockchain node 4, thereby completing the block consensus.

[0290] It should be noted that Figure 8 As shown in S802, and S803 to S806 can be executed in advance or in parallel, and Figure 8 For detailed description of S801 to S808 , please refer to the aforementioned embodiment and will not be repeated here.

[0291] In the embodiment of the present application, the transaction broadcast and transaction consensus proposal stages are integrated, which improves the efficiency and accuracy of transaction processing and saves network resources. At the same time, by utilizing the checkpoint mechanism, the efficiency and accuracy of transaction processing are further improved, and the reliability of transaction processing is greatly improved.

[0292] Figure 15 FIG is a block diagram of a transaction processing device based on blockchain, as shown in one embodiment of the present application. Figure 15 As shown, the blockchain-based transaction processing device includes:

[0293] The first receiving module 1501 is configured to receive a transaction request sent by a client and use the transaction request as a transaction request to be broadcast;

[0294] A first acquisition module 1502 is configured to acquire proposal data corresponding to the transaction request to be agreed upon;

[0295] A generating module 1503 is configured to generate a proposal request based on the proposal data and the transaction request to be broadcast;

[0296] The first sending module 1504 is configured to send the proposal request to the blockchain node, so that the blockchain node obtains the transaction request to be broadcast from the proposal request, and reaches a consensus on the transaction request to be consensus based on the proposal data in the proposal request.

[0297] In one embodiment of the present application, based on the above solution, the transaction request to be broadcast includes multiple ones; the generation module 1503 is specifically configured as follows:

[0298] Combine multiple transaction requests to be broadcast to obtain a transaction broadcast group;

[0299] The proposal data and the transaction broadcast group are encapsulated to generate a proposal request.

[0300] In one embodiment of the present application, based on the above solution, the device further includes:

[0301] An adding module configured to add the transaction request to be broadcast to the transaction pool;

[0302] Accordingly, the first acquisition module 1502 is specifically configured as follows:

[0303] Obtaining a transaction request to be agreed upon; wherein the transaction request to be agreed upon includes the transaction request to be broadcast and at least one of other transaction requests in the transaction pool, wherein the other transaction request is a transaction request other than the transaction request to be broadcast;

[0304] Proposal data corresponding to the transaction request to be agreed upon is generated based on the transaction request to be agreed upon.

[0305] In one embodiment of the present application, based on the above solution, the transaction request to be agreed upon includes multiple ones; the generation module 1503 is specifically configured as follows:

[0306] Combine multiple transaction requests to be agreed upon to obtain a transaction consensus group;

[0307] Performing a signature operation on the transaction consensus group to obtain signature data corresponding to the transaction consensus group;

[0308] Based on the signature data and the transaction consensus group, proposal data corresponding to the transaction consensus group is generated.

[0309] In one embodiment of the present application, based on the above solution, the generation module 1503 is further specifically configured as follows:

[0310] Obtaining a transaction execution order among multiple transaction requests to be agreed upon in the transaction consensus group;

[0311] Based on the transaction execution order and the signature data, proposal data corresponding to the transaction consensus group is generated; wherein, the transaction execution order is used by the blockchain node to verify the transaction execution order to complete the consensus of the transaction consensus group.

[0312] In one embodiment of the present application, based on the above solution, the blockchain node includes multiple nodes; the device further includes:

[0313] A first determination module is configured to determine, from a plurality of blockchain nodes, a first target blockchain node that has passed the transaction execution order verification;

[0314] The second determination module is configured to determine that the consensus of the transaction consensus group is passed if the number of the first target blockchain nodes reaches a first preset number threshold.

[0315] In one embodiment of the present application, based on the above solution, the generation module 1503 is further specifically configured as follows:

[0316] Executing multiple transaction requests to be agreed upon in the transaction consensus group to obtain transaction execution results;

[0317] Based on the transaction execution result and the signature data, proposal data corresponding to the transaction consensus group is generated; wherein, the transaction execution result is used by the blockchain node to verify the transaction execution result to complete the consensus of the transaction consensus group.

[0318] In one embodiment of the present application, based on the above solution, the blockchain node includes multiple nodes; the device further includes:

[0319] A third determination module is configured to determine a second target blockchain node that has verified the transaction execution result from multiple blockchain nodes;

[0320] The fourth determination module is configured to determine that the consensus of the transaction consensus group is passed if the number of the second target blockchain nodes reaches a second preset number threshold.

[0321] In one embodiment of the present application, based on the above solution, the device further includes:

[0322] A second acquisition module is configured to, if a consensus result indicating that the transaction request to be agreed upon has been passed is obtained, acquire a block generated based on a transaction execution result corresponding to the transaction request to be agreed upon;

[0323] A storage module is configured to store the block on the blockchain.

[0324] In one embodiment of the present application, based on the above solution, the device further includes:

[0325] an extraction module configured to extract, from the transaction pool, transaction requests received within a preset time period before a current time point;

[0326] a third acquisition module configured to acquire broadcast credential information corresponding to the extracted transaction request; wherein the broadcast credential information is generated based on voting information corresponding to the extracted transaction request, the voting information being generated in response to a reception status of the extracted transaction request when the extracted transaction request is broadcast;

[0327] The second sending module is configured to send the broadcast credential information to the blockchain node, so that the blockchain node detects the storage status corresponding to the extracted transaction request based on the broadcast credential information.

[0328] In one embodiment of the present application, based on the above solution, the device further includes:

[0329] a second receiving module configured to receive a request for obtaining the missing transaction request sent by the blockchain node; wherein the request for obtaining the missing transaction request is generated by the blockchain node after detecting that the transaction request is missing based on the broadcast credential information;

[0330] The third sending module is configured to send the missing transaction request to the blockchain node, so that the blockchain node performs a synchronization operation on the missing transaction request.

[0331] It should be noted that the apparatus provided in the aforementioned embodiment and the method provided in the aforementioned embodiment belong to the same concept, wherein the specific manner in which each module and unit performs operations has been described in detail in the method embodiment.

[0332] An embodiment of the present application also provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the aforementioned blockchain-based transaction processing method.

[0333] Figure 16 It is a structural diagram of a computer system suitable for implementing the electronic device of the embodiment of the present application.

[0334] It should be noted that Figure 16 The computer system 1600 of the electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present application.

[0335] like Figure 16As shown, computer system 1600 includes a central processing unit (CPU) 1601, which can perform various appropriate actions and processes according to the program stored in read-only memory (ROM) 1602 or the program loaded from storage part 1608 into random access memory (RAM) 1603, such as executing the method in the above embodiment. Various programs and data required for system operation are also stored in RAM 1603. CPU 1601, ROM 1602 and RAM 1603 are connected to each other via bus 1604. Input / output (I / O) interface 1605 is also connected to bus 1604.

[0336] The following components are connected to the I / O interface 1605: an input section 1606 including a keyboard, a mouse, and the like; an output section 1607 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1608 including a hard disk; and a communication section 1609 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 1609 performs communication processing via a network such as the Internet. A drive 1610 is also connected to the I / O interface 1605 as needed. Removable media 1611, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1610 as needed, so that computer programs read from the removable media can be installed in the storage section 1608 as needed.

[0337] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1609, and / or installed from a removable medium 1611. When the computer program is executed by the central processing unit (CPU) 1601, the various functions defined in the system of the present application are executed.

[0338] It should be noted that the computer-readable medium shown in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable media include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable computer program. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0339] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0340] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0341] Another aspect of the present application provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned blockchain-based transaction processing method. The computer-readable medium may be included in the electronic device described in the above embodiments, or may exist independently and not be incorporated into the electronic device.

[0342] Another aspect of the present application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable medium. A processor of a computer device reads the computer instructions from the computer-readable medium and executes the computer instructions, causing the computer device to perform the blockchain-based transaction processing method provided in each of the above embodiments.

[0343] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. Ordinary technicians in this field can easily make corresponding changes or modifications based on the main ideas and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A transaction processing method based on blockchain, characterized in that: include: Receive a transaction request sent by a client, and use the transaction request as a transaction request to be broadcast; Obtain the proposal data corresponding to the transaction request to be agreed upon; generating a proposal request based on the proposal data and the transaction request to be broadcast; The proposal request is sent to a blockchain node, so that the blockchain node obtains the transaction request to be broadcast from the proposal request, and reaches a consensus on the transaction request to be consensus based on the proposal data in the proposal request.

2. The method according to claim 1, characterized in that The transaction requests to be broadcast include a plurality of requests; and generating a proposal request based on the proposal data and the transaction requests to be broadcast includes: Combine multiple transaction requests to be broadcast to obtain a transaction broadcast group; The proposal data and the transaction broadcast group are encapsulated to generate a proposal request.

3. The method according to claim 1, characterized in that After taking the transaction request as a transaction request to be broadcast, the method further includes: Adding the transaction request to be broadcast to the transaction pool; The acquisition of proposal data corresponding to the transaction request to be agreed upon includes: Obtaining a transaction request to be agreed upon; wherein the transaction request to be agreed upon includes the transaction request to be broadcast and at least one of other transaction requests in the transaction pool, wherein the other transaction request is a transaction request other than the transaction request to be broadcast; Proposal data corresponding to the transaction request to be agreed upon is generated based on the transaction request to be agreed upon.

4. The method according to claim 3, characterized in that The transaction requests to be agreed upon include a plurality of items; and generating proposal data corresponding to the transaction requests to be agreed upon based on the transaction requests to be agreed upon includes: Combine multiple transaction requests to be agreed upon to obtain a transaction consensus group; Performing a signature operation on the transaction consensus group to obtain signature data corresponding to the transaction consensus group; Based on the signature data and the transaction consensus group, proposal data corresponding to the transaction consensus group is generated.

5. The method according to claim 4, characterized in that The generating, based on the signature data and the transaction consensus group, proposal data corresponding to the transaction consensus group includes: Obtaining a transaction execution order among multiple transaction requests to be agreed upon in the transaction consensus group; Based on the transaction execution order and the signature data, proposal data corresponding to the transaction consensus group is generated; wherein, the transaction execution order is used by the blockchain node to verify the transaction execution order to complete the consensus of the transaction consensus group.

6. The method according to claim 5, characterized in that The blockchain node includes a plurality of nodes; after sending the proposal request to the blockchain node, the method further includes: Determine, from a plurality of blockchain nodes, a first target blockchain node that has successfully executed sequential verification of the transaction; If the number of the first target blockchain nodes reaches a first preset number threshold, it is determined that the consensus of the transaction consensus group is passed.

7. The method according to claim 4, characterized in that The generating, based on the signature data and the transaction consensus group, proposal data corresponding to the transaction consensus group includes: Executing multiple transaction requests to be agreed upon in the transaction consensus group to obtain transaction execution results; Based on the transaction execution result and the signature data, proposal data corresponding to the transaction consensus group is generated; wherein, the transaction execution result is used by the blockchain node to verify the transaction execution result to complete the consensus of the transaction consensus group.

8. The method according to claim 7, characterized in that The blockchain node includes a plurality of nodes; after sending the proposal request to the blockchain node, the method further includes: Determine a second target blockchain node from the plurality of blockchain nodes that has verified the transaction execution result; If the number of the second target blockchain nodes reaches a second preset number threshold, it is determined that the consensus of the transaction consensus group is passed.

9. The method according to claim 1, characterized in that After sending the proposal request to the blockchain node, the method further includes: If a consensus result indicating that the transaction request to be agreed upon has been passed is obtained, a block generated based on the transaction execution result corresponding to the transaction request to be agreed upon is obtained; The block is stored on the blockchain.

10. The method according to any one of claims 1 to 9, characterized in that After receiving the transaction request sent by the client, the method further includes: Extracting transaction requests received within a preset time period before the current time point from the transaction pool; Obtaining broadcast credential information corresponding to the extracted transaction request; wherein the broadcast credential information is generated based on voting information corresponding to the extracted transaction request, the voting information being generated in response to a receipt of the extracted transaction request when the extracted transaction request is broadcast; The broadcast credential information is sent to the blockchain node, so that the blockchain node detects the storage status corresponding to the extracted transaction request based on the broadcast credential information.

11. The method according to claim 10, characterized in that After sending the broadcast credential information to the blockchain node, the method further includes: Receiving a request for the missing transaction request from the blockchain node; wherein the request is generated by the blockchain node after detecting that the transaction request is missing based on the broadcast credential information; The missing transaction request is sent to the blockchain node, so that the blockchain node performs a synchronization operation on the missing transaction request.

12. A transaction processing device based on blockchain, characterized in that: include: a receiving module configured to receive a transaction request sent by a client and use the transaction request as a transaction request to be broadcast; The acquisition module is configured to obtain the proposal data corresponding to the transaction request to be agreed upon; a generating module configured to generate a proposal request based on the proposal data and the transaction request to be broadcast; The sending module is configured to send the proposal request to the blockchain node, so that the blockchain node obtains the transaction request to be broadcast from the proposal request, and reaches a consensus on the transaction request to be agreed upon based on the proposal data in the proposal request.

13. An electronic device, characterized in that: include: one or more processors; A memory for storing one or more programs, which, when executed by the electronic device, enables the electronic device to implement the blockchain-based transaction processing method as described in any one of claims 1 to 11.

14. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the blockchain-based transaction processing method according to any one of claims 1 to 11 is implemented.

15. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, a blockchain-based transaction processing method as described in any one of claims 1 to 11 is implemented.

Images