Data processing method, apparatus and device in blockchain system, and medium

Abstract

Embodiments of the present application provide a data processing method and device in a blockchain system, equipment and medium. The blockchain system comprises at least two blockchain nodes participating in consensus, and the at least two blockchain nodes comprise a first blockchain node. The method comprises: obtaining a proposal consensus result of a first proposal; if the proposal consensus result indicates that the consensus fails, obtaining a first transaction processing quantity of the first blockchain node for the first proposal; obtaining a processed transaction set of the first blockchain node in the first proposal according to the first transaction processing quantity, generating a second proposal according to the processed transaction set; and broadcasting the second proposal in the blockchain system, so that at least two blockchain nodes in the blockchain system perform consensus processing on the second proposal. The consensus success rate of the second proposal can be improved by using the embodiments of the present application.

Description

Technical Field

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

[0002] Consensus algorithms, as the most important component for ensuring data security in a blockchain system, enable all blockchain nodes to reach the same state. In a blockchain system, depending on the transaction processing flow, there are various processing models, such as the serial deterministic scheduling model.

[0003] In the current serial deterministic scheduling model, proposal A can be initiated according to the order in which transactions are submitted to the blockchain system. When blockchain nodes execute transactions in proposal A, some transactions may fail (e.g., transaction execution timeouts). If the failure scenarios differ across blockchain nodes, consensus for proposal A will fail, and the transactions in proposal A will be returned to the transaction pool. For the blockchain node initiating the next round of proposals, it will still obtain the same transactions as proposal A and initiate a new proposal (i.e., the next round of proposal A), causing consensus for the next round of proposals to also fail. Ultimately, this may lead to the entire blockchain system being unable to reach consensus for a period of time, reducing the success rate of proposal consensus. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, and medium in a blockchain system, which can improve the consensus success rate of the second proposal.

[0005] This application provides a data processing method in a blockchain system, the blockchain system including at least two blockchain nodes participating in consensus, the at least two nodes including a first blockchain node, the method comprising:

[0006] Obtain the consensus result of the first proposal;

[0007] If the consensus result of the proposal indicates that the consensus has failed, then obtain the number of transactions processed by the first blockchain node for the first proposal;

[0008] Based on the first transaction processing count, obtain the set of processed transactions of the first blockchain node in the first proposal, and generate the second proposal based on the set of processed transactions;

[0009] The second proposal is broadcast in the blockchain system so that at least two blockchain nodes in the blockchain system can reach a consensus on the second proposal.

[0010] This application provides a data processing method in a blockchain system, the blockchain system including at least two blockchain nodes participating in consensus, the at least two nodes including a first blockchain node, the method comprising:

[0011] Receive the second proposal broadcast by the first blockchain node; the second proposal is generated based on the set of processed transactions of the first blockchain node, the set of processed transactions includes the transactions obtained in the first proposal based on the number of transactions processed by the first blockchain node for the first proposal when the consensus result of the first proposal indicates that the consensus has failed;

[0012] The second proposal was processed through consensus.

[0013] This application provides a data processing device for a blockchain system, the blockchain system including at least two blockchain nodes participating in consensus, the at least two blockchain nodes including a first blockchain node, the device comprising:

[0014] The first acquisition module is used to acquire the consensus result of the first proposal;

[0015] The second acquisition module is used to acquire the first transaction processing count of the first blockchain node for the first proposal if the consensus result of the proposal indicates that the consensus has failed.

[0016] The proposal generation module is used to obtain the set of processed transactions of the first blockchain node in the first proposal based on the first transaction processing quantity, and generate a second proposal based on the set of processed transactions.

[0017] The proposal broadcasting module is used to broadcast a second proposal in the blockchain system so that at least two blockchain nodes in the blockchain system can reach a consensus on the second proposal.

[0018] The first acquisition module is used to perform the following steps:

[0019] Obtain the first proposal, verify its validity, and obtain the proposal verification result.

[0020] If the proposal verification result indicates that the verification is successful, then the transaction in the first proposal is executed, and the execution scope of the first transaction of the first blockchain node is determined;

[0021] Based on the execution scope of the first transaction, the first voting information of the first blockchain node for the first proposal is generated, and the first voting information of the first blockchain node is broadcast in the blockchain system.

[0022] Obtain first voting information from at least two blockchain nodes regarding the first proposal; generate second voting information from the first blockchain node regarding the first proposal based on the first voting information from at least two blockchain nodes; and broadcast the second voting information from the first blockchain node in the blockchain system.

[0023] Obtain the second voting information of at least two blockchain nodes for the first proposal, and determine the consensus result of the first proposal based on the second voting information of at least two blockchain nodes.

[0024] The first acquisition module verifies the validity of the first proposal and obtains the proposal verification result, which is used to perform the following steps:

[0025] Obtain the master node identifier in the first proposal, and determine the target master node of the first proposal from at least two blockchain nodes according to the master node selection strategy in the blockchain system.

[0026] The validity of the transactions in the first proposal is verified to obtain the transaction verification results corresponding to the first proposal.

[0027] If the transaction verification result indicates that the verification is successful, and the master node identifier is the node identifier of the target master node, then the proposal verification result of the first proposal is determined to be successful.

[0028] If the transaction verification result indicates that the verification failed, or the master node identifier is not the node identifier of the target master node, then the verification result of the first proposal is determined to be that the verification failed.

[0029] If the proposal verification result indicates that the verification is successful, the first acquisition module executes the transaction in the first proposal, determines the execution scope of the first transaction of the first blockchain node, and performs the following steps:

[0030] If the proposal verification result indicates that the verification is successful, then obtain the list of transactions in the first proposal;

[0031] Determine the transaction execution time period for the first blockchain node. Within the transaction execution time period, execute the transactions in the transaction list and add the completed transactions to the executed transaction set of the first blockchain node.

[0032] The first transaction execution scope of the first blockchain node is determined based on the number of transactions in the executed transaction set.

[0033] The first acquisition module generates the first voting information of the first blockchain node for the first proposal based on the execution scope of the first transaction, which is used to execute the following steps:

[0034] Perform a hash operation on the transactions within the execution scope of the first transaction to obtain the hash of the first block corresponding to the first proposal;

[0035] The first blockchain node's private key is used to sign the first block hash and the first transaction execution scope to obtain the first blockchain node's node signature.

[0036] The first block hash, the first transaction execution scope, and the node signature are combined to form the first voting information of the first blockchain node for the first proposal.

[0037] The first acquisition module acquires first voting information from at least two blockchain nodes regarding the first proposal, and generates second voting information from the first blockchain node regarding the first proposal based on the first voting information from the at least two blockchain nodes, for use in executing the following steps:

[0038] Receive the first vote information for the first proposal broadcast by the second blockchain node, where the second blockchain node refers to the remaining blockchain node other than the first blockchain node among at least two blockchain nodes;

[0039] The second transaction execution scope of the second blockchain node is obtained from the first voting information of the second blockchain node;

[0040] Based on the first and second transaction execution scopes, the first voting information of the second blockchain node is verified to obtain the voting verification result corresponding to the first voting information of the second blockchain node.

[0041] If the voting verification result indicates that the verification is successful, the first voting information of the second blockchain node is added to the voting set; the voting set includes the first voting information of the first blockchain node.

[0042] Based on the first voting information in the voting set, determine the first transaction processing quantity of the first blockchain node;

[0043] Based on the first transaction processing quantity, generate the second voting information of the first blockchain node for the first proposal.

[0044] The first acquisition module verifies the first voting information of the second blockchain node based on the first transaction execution scope and the second transaction execution scope, and obtains the voting verification result corresponding to the first voting information of the second blockchain node, which is used to execute the following steps:

[0045] If the number of transactions within the first execution scope is greater than the number of transactions within the second execution scope, then candidate execution information corresponding to the second execution scope is determined from the transaction execution information corresponding to the first execution scope.

[0046] Perform a hash operation on the candidate execution information to obtain the verification hash of the first block;

[0047] If the first block verification hash is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

[0048] The first acquisition module verifies the first voting information of the second blockchain node based on the first transaction execution scope and the second transaction execution scope, and obtains the voting verification result corresponding to the first voting information of the second blockchain node, which is used to execute the following steps:

[0049] If the number of transactions within the execution scope of the first transaction is equal to the number of transactions within the execution scope of the second transaction, then the first block hash in the first voting information of the first blockchain node is compared with the second block hash in the first voting information of the second blockchain node.

[0050] If the hash of the first block in the first voting information of the first blockchain node is equal to the hash of the second block in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

[0051] The first acquisition module verifies the first voting information of the second blockchain node based on the first transaction execution scope and the second transaction execution scope, and obtains the voting verification result corresponding to the first voting information of the second blockchain node, which is used to execute the following steps:

[0052] If the number of transactions within the first execution scope is less than the number of transactions within the second execution scope, then the difference between the first and second execution scopes is executed to obtain the execution information of the difference.

[0053] The execution information of the differential transactions and the execution information of the transactions corresponding to the execution scope of the first transaction are hashed to obtain the verification hash of the second block;

[0054] If the second block verification hash is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

[0055] The first acquisition module determines the first transaction processing quantity of the first blockchain node based on the first voting information in the voting set, and is used to execute the following steps:

[0056] If the number of transactions within the second transaction execution range in the voting set is less than or equal to the number of transactions within the first transaction execution range, then the number of transactions within the first transaction execution range is determined as the first transaction processing number of the first blockchain node;

[0057] If the number of transactions within the second transaction execution range in the voting set is greater than the number of transactions within the first transaction execution range, then the maximum number of transactions within the second transaction execution range in the voting set will be determined as the first transaction processing number of the first blockchain node.

[0058] The first acquisition module generates second voting information for the first blockchain node regarding the first proposal based on the first transaction processing quantity, which is used to execute the following steps:

[0059] Based on the transaction indicated by the first transaction processing quantity, the first block hash in the first voting information of the first blockchain node is updated to obtain the third block hash;

[0060] Based on the first transaction processing quantity and the third block hash, the second voting information of the first blockchain node for the first proposal is generated.

[0061] The first acquisition module determines the consensus result of the first proposal based on the second voting information from at least two blockchain nodes, and is used to execute the following steps:

[0062] In the second voting information from at least two blockchain nodes, count the number of votes in favor of the first proposal;

[0063] If the number of votes in favor exceeds the voting threshold, the consensus result of the first proposal is determined to be a successful consensus.

[0064] If the number of votes in favor is less than or equal to the voting threshold, then the consensus result of the first proposal is determined to be a consensus failure.

[0065] The proposal generation module, based on the first transaction processing count, obtains the set of processed transactions from the first blockchain node in the first proposal, and generates a second proposal based on the set of processed transactions, which is used to execute the following steps:

[0066] According to the order of transactions in the transaction list of the first proposal, the transactions in the transaction list are added to the processed transaction set of the first blockchain node; the number of transactions in the processed transaction set is equal to the number of transactions processed in the first proposal.

[0067] The first transaction processing quantity and the transactions in the processed transaction set are encapsulated into a second proposal; the second proposal includes the third block hash in the second voting information of the first blockchain node.

[0068] This application provides a data processing device for a blockchain system, the blockchain system including at least two blockchain nodes participating in consensus, the at least two blockchain nodes including a first blockchain node, the device comprising:

[0069] The proposal receiving module is used to receive the second proposal broadcast by the first blockchain node. The second proposal is generated based on the set of processed transactions of the first blockchain node. The set of processed transactions includes the transactions obtained in the first proposal when the consensus result of the first proposal indicates that the consensus has failed, based on the number of transactions processed by the first blockchain node for the first proposal.

[0070] The consensus processing module is used to process the second proposal.

[0071] The second proposal includes a third block hash; the consensus processing module is used to perform the following steps:

[0072] Get the number of first transactions processed in the second proposal, and get the number of second transactions processed by the second blockchain node for the first proposal;

[0073] Based on the first and second transaction processing counts, the hash of the third block in the second proposal is verified to obtain the hash verification result;

[0074] If the hash verification result indicates that the verification passed, then the approval vote information for the second proposal is generated;

[0075] If the hash verification result indicates that the verification failed, then a second proposal's opposing vote is generated.

[0076] One aspect of this application provides a computer device, including a memory and a processor. The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the method provided in one aspect of this application.

[0077] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having a processor performs the method provided in one aspect of this application.

[0078] According to one aspect of this application, a computer program product is provided, which may include a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and executes the computer program, causing the computer device to perform the method provided in the above aspect.

[0079] In this embodiment, after the first blockchain node determines the consensus result of the first proposal, if the consensus result indicates consensus failure, it can obtain its own first transaction processing count for the first proposal. This first transaction processing count can be understood as the maximum number of transactions in the first proposal recognized by the first blockchain node. Based on the first transaction processing count, the first blockchain node obtains its processed transaction set from the first proposal, and generates a second proposal based on this set. The second proposal is then broadcast in the blockchain system so that at least two blockchain nodes in the system can perform consensus processing on it. Since the transactions in the second proposal are all transactions processed by the first blockchain node during the consensus processing of the first proposal—that is, successfully executed transactions—the normal progress of the second proposal consensus process can be guaranteed, thereby improving the consensus success rate of the second proposal. Attached Figure Description

[0080] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

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

[0082] Figure 2 This is a schematic diagram of a proposal generation provided in an embodiment of this application;

[0083] Figure 3 This is a flowchart illustrating a data processing method in a blockchain system provided in an embodiment of this application. Figure 1 ;

[0084] Figure 4 This is a schematic diagram of the processing flow of a second proposal provided in an embodiment of this application;

[0085] Figure 5 This is a flowchart illustrating a data processing method in a blockchain system provided in an embodiment of this application. Figure 2 ;

[0086] Figure 6 This is a schematic diagram illustrating the content of a first voting information provided in an embodiment of this application;

[0087] Figure 7 This is a schematic diagram illustrating the content of a second voting information provided in an embodiment of this application;

[0088] Figure 8This is a schematic diagram illustrating the process of generating first voting information for a first proposal, as provided in an embodiment of this application.

[0089] Figure 9 This is a schematic diagram illustrating the process of generating second voting information for a first proposal, as provided in an embodiment of this application.

[0090] Figure 10 This is a schematic diagram of a consensus processing flow in a blockchain system provided in an embodiment of this application;

[0091] Figure 11 This is a schematic diagram of the structure of a data processing device in a blockchain system provided in an embodiment of this application. Figure 1 ;

[0092] Figure 12 This is a schematic diagram of the structure of a data processing device in a blockchain system provided in an embodiment of this application. Figure 2 ;

[0093] Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0094] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0095] For ease of understanding, the basic technologies involved in the embodiments of this application will be described below:

[0096] Scheduling Model: The module in a blockchain system that coordinates and manages the processing model and consensus algorithm can be called the scheduling model. The scheduling model controls which consensus algorithm and processing model the blockchain system uses. Within a blockchain system, based on different transaction processing flows, there are multiple processing models, each with its own processing scheme and suitable scenarios.

[0097] The serial deterministic scheduling model is a common processing model in blockchain systems. In this model, blockchain nodes execute all transactions in a block awaiting consensus according to a serial processing strategy, obtaining the execution result of each transaction. A consensus algorithm then reaches an agreement on the transactions and execution results within the block. This model ensures that transactions are processed sequentially, guaranteeing determinism and consistency in transaction processing.

[0098] Transaction Pool (also known as Mempool): A transaction pool is a data structure in a blockchain system used to store transactions that have not yet been packaged into blocks. When a new transaction is submitted to the blockchain system, it can enter the transaction pool. Transaction pools help improve the transaction processing capacity of the blockchain system.

[0099] Transaction: A form of blockchain execution. A transaction includes the initiator's private key signature, which can guarantee the authenticity, non-forgeability, and non-repudiation of the transaction content.

[0100] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain system provided in an embodiment of this application; the blockchain system may include at least two blockchain nodes, and this application does not limit the number of blockchain nodes included in the blockchain system. Figure 1 As shown, this blockchain system uses six blockchain nodes (e.g., node 1, node 2, node 3, node 4, node 5, and node 6) as an example. The blockchain nodes are networked in a peer-to-peer manner, and can communicate with each other according to a peer-to-peer protocol. All blockchain nodes in the system jointly adhere to a broadcast mechanism and consensus algorithm to ensure the immutability and unforgeability of data in the blockchain, while simultaneously achieving the decentralized and trustless characteristics of the blockchain. The consensus algorithm can include, but is not limited to, PoW (Proof of Work), PoS (Proof of Stake), PBFT (Practical Byzantine Fault Tolerance), and TBFT (Tendermint Byzantine Fault Tolerance).

[0101] Figure 1Each blockchain node in the illustrated blockchain system can be a terminal device or a server; this application does not limit the type of blockchain node. The terminal device can be one or more of the following: PC (Personal Computer), smartphone, tablet, laptop, PDA, mobile internet device (MID), wearable device (e.g., smartwatch, smart bracelet), smart voice interaction device, smart home appliance (e.g., smart TV), in-vehicle device, aircraft, etc.; this application does not limit the type of terminal device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms; this application does not limit the type of server.

[0102] In one or more embodiments, Figure 1 The blockchain system shown illustrates how blockchain nodes can collectively maintain a blockchain, which can consist of a series of blocks. After a block is created, consensus processing must be performed within the blockchain system. Only when consensus is successful is the block allowed to be added to the blockchain. Blocks in the blockchain can be linked together in ascending order of their creation timestamps to form a chain structure. A blockchain is a distributed ledger, and the information data contained within each block of the blockchain constitutes the ledger data of that distributed ledger.

[0103] Figure 1 In the blockchain system shown, all blockchain nodes participating in the consensus process can form a consensus committee. This committee can include at least two blockchain nodes, and any one of these nodes can create a new proposal and broadcast it. Upon receiving the proposal, each blockchain node in the committee can process it for consensus. Once consensus is reached, the transaction data in the proposal can be added to the blockchain in the form of blocks.

[0104] In this context, a proposal can refer to a suggestion or request from a blockchain node in the consensus committee regarding changes to blockchain data or state. A proposal may include, but is not limited to, transaction data, a proposal identifier, the identifier of the proposal initiator, the proposal creation time, and the number of transactions. This application does not limit the information contained in the proposal. The transaction data in the proposal can be represented in the form of blocks; that is, a proposal can include one block. The blockchain node that initiates the proposal can be called the master node (or the proposal node, or the block generating node). The transaction data in the proposal can include at least one transaction. The proposal identifier can refer to information such as a number or symbol used to uniquely identify the proposal. The identifier of the proposal initiator can refer to the node identifier of the master node, such as the master node's network address, node ID (identity document), public key, etc. This application does not limit this. The proposal creation time can refer to the timestamp of the master node creating the proposal. The number of transactions can refer to the number of transactions contained in the proposal.

[0105] Please see Figure 2 , Figure 2 This is a schematic diagram of a proposal generation provided in an embodiment of this application. Figure 2 Blockchain node A and blockchain node B shown are blockchain nodes in the consensus committee of the blockchain system. When blockchain node A is the master node, blockchain node A can fetch a batch of transactions from transaction pool 20a, such as transactions tx1, tx2, tx3, tx4, tx5 and tx6 in transaction pool 20a, and create proposal 20b based on this batch of transactions.

[0106] Transaction pool 20a can be the transaction pool corresponding to blockchain node A. Transaction pool 20a can be used to store transactions received by blockchain node A that have not yet been packaged into blocks. Transactions in transaction pool 20a can be sorted according to their submission time; the earlier the submission time, the higher the ranking of the transaction in transaction pool 20a. The transaction submission time refers to the time the transaction is submitted to the blockchain system. For example, if a user submits transaction tx1 to the blockchain system through a blockchain client on an off-chain device at xx:xx on xxxx, then the transaction submission time of transaction tx1 is xx:xx on xxxx. An off-chain device can refer to an electronic device outside the blockchain system, such as a terminal device or server, which can run a blockchain client. A blockchain client can be any client with blockchain transaction submission capabilities.

[0107] Understandably, each blockchain node in the consensus committee corresponds to a transaction pool, and the transactions contained in the transaction pools of different blockchain nodes can be the same or different. For example, when a blockchain node in the consensus committee experiences a network failure (such as network latency or network disconnection), the transactions in the transaction pool corresponding to that blockchain node may differ from the transactions in the transaction pools corresponding to other blockchain nodes.

[0108] like Figure 2 As shown, the transactions in transaction pool 20a corresponding to blockchain node A, ordered by their submission time, can be represented sequentially as: transaction tx1, transaction tx2, transaction tx3, ... Proposal 20b may include proposal identifier 20c, and multiple transactions (such as transactions tx1 to tx6) extracted by blockchain node A from transaction pool 20a. When the blockchain system uses a serial deterministic scheduling processing model, the six transactions in proposal 20b can be extracted from transaction pool 20a in chronological order of their submission time. These six transactions are represented as blocks in proposal 20b; that is, proposal 20b contains one block containing the aforementioned six transactions.

[0109] The proposal identifier 20c can refer to at least one of the following information used to characterize the proposal 20b: proposal number (used to distinguish different proposals), blockchain network identifier (used to determine the blockchain network where the proposal 20b is located), proposal topic category (such as transaction proposal, parameter adjustment proposal, block proposal, etc.), master node identifier (such as the node identifier of blockchain node A), proposal creation time, etc. This application does not limit this information.

[0110] In one feasible implementation, the blockchain system can pre-set a maximum number of transactions in each proposal, or it can be understood as the maximum number of transactions that a block can contain. For example, when the maximum number of transactions is set to 6, the number of transactions contained in each proposal is less than or equal to 6. This application embodiment uses proposal 20b, which includes 6 transactions (transaction tx1, transaction tx2, ..., transaction tx6), as an example for description.

[0111] After blockchain node A creates proposal 20b, it can broadcast proposal 20b throughout the blockchain system, ensuring that all blockchain nodes in the consensus committee can access it. Each node in the consensus committee can then process proposal 20b to obtain its consensus result; this consensus process will be described in detail later. If the consensus result of proposal 20b indicates successful consensus, the six transactions in proposal 20b can be stored as blocks in blockchain 20d. At this point, blockchain node A can remove these six transactions from transaction pool 20a. It should be understood that when consensus on proposal 20b is successful, each blockchain node in the consensus committee can remove these six transactions from its own transaction pool.

[0112] Furthermore, a next master node, such as blockchain node B, can be selected from the consensus committee. Blockchain node B can extract a new batch of transactions from its own transaction pool, such as transactions tx7, tx8, tx9, tx10, tx11, and tx12, and create a new proposal 20e based on this batch of new transactions. The content structure of proposal 20e is the same as that of proposal 20b, both of which can include a proposal identifier and a batch of transactions. For example, proposal 20e can include proposal identifier 20f and transactions tx7 to tx12 extracted from the transaction pool; the consensus processing process of proposal 20e is the same as that of proposal 20b.

[0113] In a blockchain system, the master node for each round of proposals can be selected according to the order of the blockchain nodes in the consensus committee, or according to the order of their credibility from highest to lowest, or according to other selection methods. This application does not limit the selection method for the master node in the blockchain system. Credibility can be determined by the validity of proposals created by each blockchain node within a past period (e.g., one day, one month, six months, etc.). For example, if all proposals created by blockchain node B within a past period are valid, then blockchain node B has high credibility; if only 50% of the proposals created by blockchain node B within that period are valid, then blockchain node B has low credibility.

[0114] Optionally, if the consensus result of proposal 20b indicates consensus failure, the next master node in the consensus committee (such as blockchain node B) does not need to return transactions tx1 to tx6 in proposal 20b to the transaction pool to re-initiate the proposal. Instead, it uses the maximum number of transactions that blockchain node B recognized (e.g., successfully executed) during the consensus processing of proposal 20b but did not reach consensus, to create a new proposal 20g. The content of proposal 20g differs from that of proposal 20b. Proposal 20g may include, but is not limited to: a proposal identifier 20h, all transactions recognized by blockchain node B during the consensus processing of proposal 20b, the maximum number of transactions processed 20i, and the block hash 20j calculated by blockchain node B during the consensus processing of proposal 20b. The block hash 20j may refer to the hash value calculated by blockchain node B for the blocks in proposal 20g.

[0115] like Figure 2 As shown, the proposal number in proposal identifier 20h can be the same as or different from the proposal number in proposal identifier 20c. That is, a new proposal number can be created for proposal 20g, or the proposal number of proposal 20b, which failed in the previous consensus round, can be used. This application does not impose any restrictions on this. Assuming that blockchain node B approves transactions tx1, tx2, tx3, tx4, and tx5 during the consensus processing of proposal 20b, then blockchain node B can create proposal 20g based on the approved transactions tx1 to tx5. In addition to proposal identifier 20h and the aforementioned transactions tx1 to tx5, proposal 20g can also include the maximum number of transactions processed 20i and the block hash 20j. The maximum number of transactions processed 20i can be represented as the number of transactions approved by blockchain node B during the consensus processing of proposal 20b. Block hash 20j can be obtained by hashing transactions tx1 to tx5 recognized by blockchain node B; this block hash 20j can be calculated by hashing when creating proposal 20g, or it can be directly obtained from the consensus information of the previous round of proposal 20b, and this application does not limit it in this way. The hashing process of block hash 20j will be described in the following content.

[0116] It should be noted that for transaction tx6 in Proposal 20b, since it failed to be recognized by the next master node (blockchain node B) during the consensus processing of Proposal 20b, transaction tx6 can be returned to the transaction pool.

[0117] After blockchain node B creates proposal 20g, it can broadcast proposal 20g within the blockchain system. Each blockchain node in the consensus committee can then utilize the consensus information from the previous round of proposal 20b's consensus processing to perform consensus processing on proposal 20g, obtaining the proposal consensus result. The consensus processing procedure for proposal 20g will be described later.

[0118] In this embodiment of the application, in the event that the consensus of the previous round of proposal 20b fails, the number of transactions recognized by the blockchain nodes can be preserved to the greatest extent possible, ensuring the normal execution of the next round of proposal 20g and improving the consensus efficiency of the blockchain system.

[0119] Please see Figure 3 , Figure 3 This is a flowchart illustrating a data processing method in a blockchain system provided in an embodiment of this application. Figure 1 Understandably, this method can be executed by a first blockchain node, which can be any blockchain node participating in the consensus within the blockchain system, i.e., any blockchain node in the consensus committee. For example... Figure 3 As shown, the data processing method in this blockchain system may include at least the following steps S101 to S104:

[0120] Step S101: Obtain the consensus result of the first proposal.

[0121] In this embodiment of the application, the first blockchain node may refer to the first proposal in the blockchain system (e.g., Figure 2 The master node of the next round of proposals in the corresponding embodiment (20b), and the first blockchain node is the slave node of the first proposal (also known as a non-proposal node), such as... Figure 2 The corresponding blockchain node B in the embodiment. The first proposal may refer to the preceding master node of the first blockchain node (for ease of understanding, it can be called the target master node, such as...). Figure 2 In the corresponding embodiment, blockchain node A extracts a sufficient number of proposals created by exchanges from the transaction pool.

[0122] The blockchain system involved in this application embodiment can be a serial deterministic scheduling processing model. In this serial deterministic scheduling processing model, transactions are executed in the order of the proposal. Therefore, for the first blockchain node, it is possible to accurately determine whether the proposal voting information broadcast by other blockchain nodes is reasonable.

[0123] Each participating blockchain node can obtain the consensus result of the first proposal according to the consensus algorithm in the serial deterministic scheduling processing model. For example, the first blockchain node can use the consensus algorithm to process the first proposal and obtain the first blockchain node's proposal voting information. During the consensus processing of the first proposal, the proposal voting information of each blockchain node can be broadcast in the blockchain system; that is, the first blockchain node can receive the proposal voting information of other blockchain nodes for the first proposal. The first blockchain node can count the received proposal voting information of the first proposal (including the first blockchain node's own proposal voting information) to obtain the number of affirmative votes for the first proposal; if the number of affirmative votes is greater than the voting threshold, it can be determined that the first proposal has reached a consensus among at least two blockchain nodes included in the consensus committee, that is, the proposal consensus result of the first proposal is a successful consensus, and the block in the first proposal can be added to the blockchain and the state data of the blockchain can be updated; if the number of affirmative votes is less than or equal to the voting threshold, it can be determined that the first proposal has not reached a consensus among at least two blockchain nodes included in the consensus committee, that is, the proposal consensus result of the first proposal is a failed consensus.

[0124] The voting threshold can refer to the minimum requirement for a proposal to reach consensus in a blockchain system. This threshold can be determined based on the consensus algorithm used by the blockchain system. For example, the voting threshold can be set to 50% of the number of blockchain nodes in the consensus committee, or it can be 2 / 3 of the number of blockchain nodes in the consensus committee. This application does not limit this. Different consensus algorithms used by blockchain systems may lead to differences in the consensus processing flow of the first proposal, and the content contained in the proposal voting information may also differ. The proposal voting information of the first proposal can be used to indicate whether each blockchain node agrees to add the block in the first proposal to the blockchain, or it can be used to indicate the transactions recognized by each blockchain node during the consensus processing of the first proposal.

[0125] In one feasible implementation, when the proposal voting information of the first proposal is used to indicate whether each blockchain node agrees to add the block in the first proposal to the blockchain, the proposal voting information of the first proposal may include affirmative votes and negative votes; affirmative votes indicate that the blockchain node agrees to add the block in the first proposal to the blockchain, and negative votes indicate that the blockchain node disagrees to add the block in the first proposal to the blockchain. The first blockchain node can count the number of affirmative votes among all the proposal voting information it receives for the first proposal, and determine the number of affirmative votes as the number of affirmative votes for the first proposal.

[0126] In one feasible implementation, when the proposal voting information of the first proposal is used to instruct each blockchain node on the transactions recognized during the consensus processing of the first proposal, the proposal voting information of the first proposal may include some or all of the information such as which transactions each blockchain node recognizes, the number of recognized transactions, the block hash calculated based on the recognized transactions, and the signatures of each blockchain node. This application does not limit this.

[0127] The first blockchain node can categorize and count all the proposal voting information it receives for the first proposal, obtaining the number of nodes in each category. The node with the largest number of nodes in each category is determined as the number of "yes" votes for the first proposal. For example, suppose the proposal voting information of blockchain node d1 for the first proposal is denoted as voting information m1, and the proposal voting information of blockchain node d2 for the first proposal is denoted as voting information m2. If the number of approved transactions and the block hash are the same in voting information m1 and voting information m2, then voting information m1 and voting information m2 can be classified into the same category of proposal voting information; that is, blockchain nodes d1 and d2 have reached a consensus on the processing of the first proposal. The number of nodes in each category of proposal voting information can refer to the number of nodes in the consensus committee that have reached a consensus on the processing of the first proposal. The category of proposal voting information with the largest number of nodes can be used as the number of "yes" votes for the first proposal.

[0128] For ease of understanding, this application uses a BFT (Byzantine Fault Tolerance) consensus algorithm (e.g., PBFT, TBFT, etc.) as an example to process the consensus of the first proposal. The consensus processing of the first proposal can include three stages: the proposal stage, the pre-voting stage, and the pre-commit stage; or they can be referred to as the first stage, the second stage, and the third stage. This application does not limit the names of the three stages in the consensus processing. Each stage in the consensus processing can be set with a timer, which can be used to set the effective duration of each stage. The effective durations of different stages can be the same or different, and can be specifically set according to the actual application scenario. This application does not limit the setting of the effective durations of different stages. When processing the first proposal, each blockchain node needs to perform the corresponding operation within the effective duration of each stage. Regardless of whether the blockchain node completes the corresponding operation within the effective duration of each stage, it can proceed to the next stage. For example, if a blockchain node does not create a new proposal within the effective duration of the proposal stage, it will still enter the pre-voting stage.

[0129] During the proposal phase of the first proposal, a target master node can be selected from the consensus committee. This target master node can be any blockchain node in the consensus committee other than the first blockchain node. The target master node can package a batch of transactions from its own transaction pool to create the first proposal; that is, the target master node can refer to the blockchain node that created the first proposal. The target master node can then broadcast the first proposal to other blockchain nodes in the consensus committee (such as the slave nodes of the first proposal) for consensus processing.

[0130] The slave nodes of the first proposal can receive the first proposal broadcast by the target master node. After receiving the first proposal, the slave nodes enter the pre-voting phase. During the pre-voting phase of the first proposal, each blockchain node in the consensus committee (including the target master node and slave nodes) can perform pre-voting processing (the first vote) on the first proposal, obtaining the first voting information of each blockchain node (also called pre-voting information); the information contained in the first voting information will be described later. Each blockchain node can broadcast its own first voting information, and after the valid duration of the pre-voting phase has elapsed, it can enter the pre-commit phase.

[0131] During the pre-submission phase of the first proposal, each blockchain node in the consensus committee can pre-submit (second vote) the first proposal based on the first vote information it receives, obtaining the second vote information (also known as pre-submission information) from each blockchain node. The generation process of the second vote information and the information contained in the second vote information will be described later. It is understandable that due to network failures, equipment failures, or other reasons, some blockchain nodes may fail to receive the first vote information broadcast by other blockchain nodes within the valid duration of the pre-voting phase; that is, the number of first votes received by each blockchain node in the consensus committee may be less than or equal to the number of blockchain nodes in the consensus committee.

[0132] It is understood that the consensus processing procedures (including pre-voting and pre-committing) of each slave node of the first proposal are similar. For ease of understanding, this application uses the first blockchain node as an example to describe the consensus processing procedure of the first proposal. In the consensus processing flow of BFT-type consensus algorithms, the proposal voting information of the first proposal may refer to the first voting information and the second voting information of the first proposal, or it may refer to the second voting information of the first proposal. This application does not limit this.

[0133] Step S102: If the consensus result of the proposal indicates that the consensus has failed, then obtain the number of transactions processed by the first blockchain node for the first proposal.

[0134] Specifically, if the consensus result of the first proposal indicates consensus failure, the first blockchain node, as the master node for the next round of proposals, does not need to return the transactions contained in the first proposal to the transaction pool. Instead, it obtains the number of transactions recognized by the first blockchain node during the consensus processing of the first proposal, i.e., the first transaction processing count. Figure 2 The maximum number of transactions processed in the corresponding embodiment is 20i.

[0135] The first transaction processing quantity can refer to the maximum number of transactions processed (executed) by the first blockchain node during the consensus processing of the first proposal; or it can be understood as the scope of transaction execution by the first blockchain node during the consensus processing of the first proposal. For example, the first transaction processing quantity indicates which specific transaction in the first proposal the first blockchain node executed during the consensus processing of the first proposal. Transactions processed (executed) by the first blockchain node during the consensus processing of the first proposal can be considered transactions approved by the first blockchain node. The first transaction processing quantity is less than or equal to the total number of transactions in the first proposal. For example, a first transaction processing quantity of 5 indicates that the first blockchain node processed (executed) the following transactions during the consensus processing of the first proposal: the first transaction tx1, the second transaction tx2, the third transaction tx3, the fourth transaction tx4, and the fifth transaction tx5 of the first proposal.

[0136] Step S103: Based on the first transaction processing quantity, obtain the set of processed transactions of the first blockchain node in the first proposal, and generate the second proposal based on the set of processed transactions.

[0137] Specifically, transactions in the transaction list of the first proposal are added to the processed transaction set of the first blockchain node according to their order of arrangement, until the number of transactions in the processed transaction set reaches the first transaction processing limit. The first transaction processing limit and the transactions in the processed transaction set are then encapsulated into the second proposal. In this second proposal, the transactions in the processed transaction set can be packaged into a new block, and the consensus processing process of the second proposal is essentially the consensus processing process for the new block. The transaction list of the first proposal can refer to a transaction set sorted according to a certain order, containing all transactions in the first proposal. This sorting order can refer to the order in which the transactions were submitted. The order of transactions in the processed transaction set in the second proposal is the same as the order of transactions in the processed transaction set in the first proposal.

[0138] Understandably, transactions in the first proposal's transaction list that are not included in the already processed transaction set can be returned to the transaction pool to await the next round of proposals. For example, if the first proposal's transaction list contains 6 transactions (e.g., transactions tx1 to tx6), and the first blockchain node recognizes a maximum of 5 transactions (e.g., transactions tx1 to tx5) during the consensus processing of the first proposal, meaning the already processed transaction set contains 5 transactions, then transaction tx6 can be returned to the transaction pool to await the next round of proposals.

[0139] In one feasible implementation, the second proposal created by the first blockchain node may include, in addition to the aforementioned first transaction processing quantity and processed transaction set, a proposal identifier for the second proposal, and a block hash (which can be referred to as the third block hash for ease of understanding) calculated by the first blockchain node during the consensus processing of the first proposal based on the transactions in the processed transaction set. Figure 2 The corresponding embodiment includes information such as the block hash 20j). The third block hash can be the block hash in the second voting information of the first blockchain node for the first proposal; when the first blockchain node creates the second proposal, it does not need to recalculate the third block hash, but can directly obtain it from the second voting information of the first blockchain node for the first proposal. The second proposal can be the next round of proposals for the first proposal, and the content of the second proposal can be as follows: Figure 2 As shown in Proposal 20g in the corresponding embodiment, it will not be described again here.

[0140] In one feasible implementation, provided that the number of transactions in the second proposal is less than or equal to a pre-set maximum number of transactions, the second proposal may only include transactions from the processed transaction set of the first blockchain node; alternatively, the second proposal may include, in addition to transactions from the processed transaction set, unprocessed transactions extracted from the transaction pool, which is not limited in this application. For example, if the pre-set maximum number of transactions is 6, and the number of transactions in the processed transaction set is 5, the second proposal may include, in addition to the 5 transactions from the processed transaction set, one unprocessed transaction extracted from the transaction pool and packaged into the new block of the second proposal.

[0141] Step S104: Broadcast the second proposal in the blockchain system so that at least two blockchain nodes in the blockchain system can reach a consensus on the second proposal.

[0142] Specifically, after the first blockchain node creates the second proposal, it can broadcast the second proposal within the blockchain system so that all other blockchain nodes in the consensus committee, excluding the first blockchain node, can receive it. For ease of understanding, the other blockchain nodes in the consensus committee, excluding the first blockchain node, can be referred to as second blockchain nodes. Second blockchain nodes can also be referred to as slave nodes of the second proposal. The number of second blockchain nodes can be one or more; in this application's embodiments, "multiple" refers to two or more.

[0143] The second blockchain node can receive the second proposal broadcast by the first blockchain node, and then perform consensus processing on the second proposal. It is understandable that when there are multiple second blockchain nodes, the consensus processing process for the second proposal is similar for each second blockchain node; for ease of understanding, the consensus processing process for the second proposal will be described below using any one second blockchain node (e.g., second blockchain node n1) as an example.

[0144] After receiving the second proposal, the second blockchain node n1 can obtain the first transaction processing count in the second proposal and the second transaction processing count of the second blockchain node n1 for the first proposal. Based on the first and second transaction processing counts, it verifies the hash of the third block in the second proposal and obtains the hash verification result. If the hash verification result indicates that the verification is successful, it can generate a vote in favor of the second proposal. If the hash verification result indicates that the verification is unsuccessful, it can generate a vote against the second proposal.

[0145] The second transaction processing quantity can refer to the maximum number of transactions processed (executed) by the second blockchain node (e.g., second blockchain node n1) during the consensus processing of the first proposal; or it can be understood as the scope of transaction execution by the second blockchain node n1 during the consensus processing of the first proposal. For example, the second transaction processing quantity is used to indicate which specific transaction in the first proposal the second blockchain node executed during the consensus processing of the first proposal. The aforementioned positive and negative voting information of the second proposal can both be considered as: the first voting information of the second blockchain node n1 during the consensus processing of the second proposal (e.g., the pre-voting information in the pre-voting stage); the positive voting information indicates that the second blockchain node n1 agrees to add the block in the second proposal to the blockchain, and the negative voting information indicates that the second blockchain node n1 disagrees with adding the block in the second proposal to the blockchain.

[0146] Please see Figure 4 , Figure 4This is a schematic diagram of the processing flow of a second proposal provided in an embodiment of this application. It can be understood that the processing flow of the second proposal is similar for all slave nodes (second blockchain nodes). The processing flow of the second proposal is described below using the second blockchain node n1 as an example.

[0147] like Figure 4 As shown, the processing flow for the second proposal may include the following steps S201 to S210:

[0148] Step S201: parse the second proposal, verify the validity (reasonableness) of the second proposal.

[0149] Specifically, after receiving the second proposal, the second blockchain node n1 can parse it to obtain the master node identifier (e.g., node number, node ID, node public key, etc.) and the transactions contained in the proposal. It can verify the validity of the transactions, such as whether the initiator's account balance is sufficient to support the transaction's expenditure, whether the transaction's structure and data format conform to blockchain specifications, and whether the source of the transaction input is legitimate and not reused. If all transactions in the second proposal pass each of these verifications, the transactions in the second proposal are considered valid. If any transaction in the second proposal fails one or more of these verifications, it is considered an invalid transaction.

[0150] The second proposal is valid if all transactions in it are valid, and the master node identifier in the second proposal indicates the first blockchain node. In other words, the second proposal received by the second blockchain node n1 is valid. Conversely, the second proposal is invalid if it contains invalid transactions, or if the master node identifier in the second proposal does not indicate the first blockchain node. In other words, the second proposal received by the second blockchain node n1 is invalid.

[0151] Step S202: Obtain information such as the number of first transactions processed (which can be denoted as TxEnd21) and the third block hash (which can be denoted as BlockHash21) from the second proposal.

[0152] Step S203: Obtain from the local cache the second blockchain node n1 the number of transactions processed in the consensus process of the first proposal (which can be denoted as TxEnd22) and the fourth block hash (which can be denoted as BlockHash22).

[0153] Specifically, after verifying the validity of the second proposal, the second blockchain node n1 can obtain the first transaction processing quantity TxEnd21 and the third block hash BlockHash21 contained in the second proposal. Based on the content contained in the second proposal (e.g., the first transaction processing quantity TxEnd21), it can be determined that the second proposal contains transactions processed in the previous round of consensus processing (i.e., the consensus processing of the first proposal); thus, the second transaction processing quantity TxEnd22 and the fourth block hash BlockHash22 of the previous round of consensus of the second blockchain node n1 can be obtained from the local cache.

[0154] Wherein, the fourth block hash BlockHash22 can be the block hash in the second voting information of the second blockchain node n1 for the first proposal; the fourth block hash BlockHash22 is the block hash value obtained by the second blockchain node n1 through hashing all transactions (the transactions indicated by the second transaction processing quantity TxEnd22) executed during the consensus processing of the first proposal. The aforementioned local cache can be used to store consensus information generated by the second blockchain node n1 in the previous round of consensus processing, such as the first voting information, second voting information, transaction execution information, etc. of the second blockchain node n1 in the previous round of consensus processing. The transaction execution information may include the transaction execution result, transaction time, transaction initiator, transaction recipient, transaction status, etc. of the second blockchain node n1 in the previous round of consensus processing, which is not limited in this application.

[0155] Step S204: Determine the size relationship between the first transaction processing quantity TxEnd21 and the second transaction processing quantity TxEnd22.

[0156] Specifically, when the first transaction processing quantity TxEnd21 and the second transaction processing quantity TxEnd22 are equal, step S205 can be executed; when the first transaction processing quantity TxEnd21 is less than the second transaction processing quantity TxEnd22, steps S206 to S207 can be executed; when the first transaction processing quantity TxEnd21 is greater than the second transaction processing quantity TxEnd22, steps S208 to S210 can be executed.

[0157] Step S205: Determine whether the hash of the third block (BlockHash21) and the hash of the fourth block (BlockHash22) are equal.

[0158] Specifically, when the number of transactions processed in the first block (TxEnd21) and the number of transactions processed in the second block (TxEnd22) are equal, the relationship between the hashes of the third block (BlockHash21) and the fourth block (BlockHash22) is further determined. If the hashes of the third block (BlockHash21) and the fourth block (BlockHash22) are equal, then it can be determined that the hash of the third block (BlockHash21) in the second proposal has passed the verification of the second blockchain node n1, meaning the above hash verification result indicates that the verification has passed. The second blockchain node n1 can then generate the first voting information for the second proposal. This first voting information can be an affirmative vote, indicating that the second blockchain node n1 recognizes the second proposal and agrees to add the transactions in the second proposal to the blockchain. For ease of understanding, the first voting information for the second proposal can be referred to as the third voting information.

[0159] If the hash of the third block, BlockHash21, and the hash of the fourth block, BlockHash22, are not equal, then it can be determined that the hash of the third block, BlockHash21, in the second proposal has not passed the verification of the second blockchain node n1. That is, the above hash verification result indicates that the verification has failed. The second blockchain node n1 can generate the third voting information for the second proposal. At this time, the third voting information can be the dissenting voting information, indicating that the second blockchain node n1 does not recognize the second proposal and does not agree to add the transaction in the second proposal to the blockchain.

[0160] Step S206: Calculate the hash of the first candidate block (which can be denoted as BlockHash23) based on the local transaction execution information of the second blockchain node n1 in the consensus processing of the first proposal and the number of first transactions TxEnd21.

[0161] The local transaction execution information can refer to the transaction execution information of the second blockchain node n1 during the consensus processing of the first proposal. The first candidate block hash BlockHash23 can refer to the block hash recalculated by the second blockchain node n1 based on its local transaction execution information in the previous consensus processing, for the transaction indicated by the first transaction processing quantity TxEnd21.

[0162] Specifically, when the first transaction processing quantity TxEnd21 is less than the second transaction processing quantity TxEnd22, the second blockchain node n1 can obtain the transaction execution information corresponding to the exchange indicated by the first transaction processing quantity TxEnd21 from the local transaction execution information; and recalculate the block hash, i.e., the first candidate block hash BlockHash23, based on the transaction execution information corresponding to the exchange indicated by the first transaction processing quantity TxEnd21.

[0163] Step S207: Determine whether the hash of the third block, BlockHash21, is equal to the hash of the first candidate block, BlockHash23.

[0164] Specifically, if the hash of the third block, BlockHash21, is equal to the hash of the first candidate block, BlockHash23, then it can be determined that the hash of the third block, BlockHash21, has passed the verification of the second blockchain node n1, that is, the above hash verification result indicates that the verification is successful; the second blockchain node n1 can generate the third voting information of the second proposal, and the third voting information at this time can be the voting information in favor.

[0165] If the hash of the third block, BlockHash21, is not equal to the hash of the first candidate block, BlockHash23, then it can be determined that the hash of the third block, BlockHash21, has not passed the verification of the second blockchain node n1. That is, the above hash verification result indicates that the verification has failed. The second blockchain node n1 can generate the third voting information for the second proposal. At this time, the third voting information can be the information of opposing the proposal.

[0166] Step S208: Based on the first transaction processing quantity TxEnd21, execute the transactions that differ between the first transaction processing quantity TxEnd21 and the second transaction processing quantity TxEnd22.

[0167] Specifically, when the first transaction processing quantity TxEnd21 is greater than the second transaction processing quantity TxEnd22, the transaction that differs between the second transaction processing quantity TxEnd22 and the first transaction processing quantity TxEnd21 can be executed, and the execution information of the transaction that differs between the two can be obtained. For example, when the second transaction processing quantity TxEnd22 is 4 and the first transaction processing quantity TxEnd21 is 5, it means that the transactions completed by the second blockchain node n1 in the previous consensus processing are: transactions tx1 to tx4, and the transactions completed by the first blockchain node in the previous consensus processing are: transactions tx1 to tx5; at this time, the second blockchain node n1 can execute the transaction tx5 that differs between the two, and obtain the execution information of transaction tx5.

[0168] Step S209: Based on the difference in transaction execution information between the two, and the local transaction execution information of the second blockchain node n1 in the consensus processing of the first proposal, calculate the hash of the second candidate block (which can be denoted as BlockHash24).

[0169] Specifically, based on the transaction execution information between the second transaction processing quantity TxEnd22 and the first transaction processing quantity TxEnd21, and the local transaction execution information of the second blockchain node n1 in the previous consensus processing process, the block hash, namely the second candidate block hash BlockHash24, can be recalculated for the transaction indicated by the first transaction processing quantity TxEnd21.

[0170] Step S210: Determine whether the hash of the third block, BlockHash21, is equal to the hash of the second candidate block, BlockHash24.

[0171] Specifically, if the hash of the third block, BlockHash21, is equal to the hash of the second candidate block, BlockHash24, then it can be determined that the hash of the third block, BlockHash21, has passed the verification of the second blockchain node n1, that is, the above hash verification result indicates that the verification is successful; the second blockchain node n1 can generate the third voting information of the second proposal, and the third voting information at this time can be the voting information in favor.

[0172] If the hash of the third block, BlockHash21, is not equal to the hash of the second candidate block, BlockHash24, then it can be determined that the hash of the third block, BlockHash21, has not passed the verification of the second blockchain node n1. That is, the above hash verification result indicates that the verification has failed. The second blockchain node n1 can generate the third voting information for the second proposal. At this time, the third voting information can be the information of opposing the proposal.

[0173] After the second blockchain node n1 generates the third voting information for the second proposal, it can broadcast the third voting information of the second blockchain node n1 on the second proposal in the blockchain system. This allows both the master node and the slave node of the second proposal to receive the third voting information of the second blockchain node n1.

[0174] Understandably, after generating their own third voting information for the second proposal, other slave nodes can also broadcast their generated third voting information within the blockchain system. The first blockchain node, acting as the master node for the second proposal, generates affirmative votes for the second proposal. The second blockchain node n1 can acquire the third voting information from each blockchain node within the valid duration of the pre-voting phase. It can then count the number of affirmative votes among the third voting information received by the second blockchain node n1. If the number of affirmative votes in the pre-voting phase is less than or equal to the voting threshold, the consensus processing for the second proposal can be terminated, indicating that the second proposal has not reached a consensus. If the number of affirmative votes in the pre-voting phase is greater than the voting threshold, the next phase, such as the pre-commit phase, can proceed.

[0175] During the pre-submission phase of the second proposal, the second blockchain node n1 can vote on the second proposal a second time, generating a fourth vote message for the second proposal. This fourth vote message can be either a positive or negative vote message. The second blockchain node n1 can broadcast its generated fourth vote message within the blockchain system, allowing all blockchain nodes to receive it.

[0176] The second blockchain node n1 can obtain the fourth voting information from each blockchain node within the valid time of the pre-submission phase. It can then count the number of "yes" votes among the fourth votes received. If the number of "yes" votes in the pre-submission phase is greater than the voting threshold, it can be determined that the second proposal has reached consensus, and the block in the second proposal is added to the blockchain. If the number of "yes" votes in the pre-submission phase is less than or equal to the voting threshold, it can be determined that the second proposal has not reached consensus, and the next master node can be selected in the consensus committee according to... Figure 3 and Figure 4 As described in the corresponding embodiment, the next round of consensus processing for the proposal is carried out until the proposal consensus is successful.

[0177] This application proposes an optimized processing model based on the serial deterministic scheduling model. This optimized model maximizes the retention of completed transactions in cases where the first proposal consensus fails, allowing for the creation of the next round of proposals (the second proposal). Since the transactions in the second proposal are those successfully executed by the first blockchain node during the first proposal's consensus processing, the normal progress of the second proposal consensus process is guaranteed, improving the success rate of the second proposal consensus and enhancing the consensus efficiency of the blockchain system.

[0178] Please see Figure 5 , Figure 5 This is a flowchart illustrating a data processing method in a blockchain system provided in an embodiment of this application. Figure 2 Understandably, this method can be executed by a first blockchain node, which can be any blockchain node in the consensus committee. For example... Figure 5 As shown, the data processing method in this blockchain system may include at least the following steps S301 to S308:

[0179] Step S301: Obtain the first proposal, verify the validity of the first proposal, and obtain the proposal verification result of the first proposal.

[0180] Specifically, the first blockchain node can receive the first proposal broadcast in the blockchain system and verify its validity to obtain a proposal verification result. The verification result can be either "verification passed" or "verification failed." If the verification result indicates that the verification passed, subsequent steps can be executed. If the verification result indicates that the verification failed, the first proposal can be determined to be invalid and discarded.

[0181] In one feasible implementation, the validity verification process of the first proposal may include, but is not limited to: obtaining the master node identifier in the first proposal; and, according to the master node selection strategy in the blockchain system, determining the target master node of the first proposal from at least two blockchain nodes. If the master node identifier in the first proposal is the node identifier of the target master node, then the master node of the first proposal is valid; if the master node identifier in the first proposal is not the node identifier of the target master node, then the master node of the first proposal is invalid. The master node selection strategy can refer to the rules for selecting the master node for each round of proposals from the consensus committee, also known as the master node selection method; the master node selection strategy can be found in [reference needed]. Figure 2 The description of the selection method of the master node in the corresponding embodiment will not be repeated here.

[0182] The first blockchain node can verify the validity of transactions in the first proposal, obtaining a transaction verification result corresponding to the first proposal. This result can be either "verified" or "failed." Transaction validity verification may include, but is not limited to: verifying whether the initiator's account balance is sufficient to support the transaction's expenditure, verifying that the transaction's structure and data format conform to blockchain specifications, and verifying that the source of the transaction input is legitimate and has not been reused. When all transactions in the first proposal pass verification, the transaction verification result for the first proposal is "verified"; when any one or more transactions in the first proposal fail verification, the transaction verification result for the first proposal is "failed."

[0183] If the transaction verification result indicates successful verification, and the master node identifier is the same as the target master node's node identifier, then the first proposal's verification result is determined to be successful. If the transaction verification result indicates unsuccessful verification, or the master node identifier is not the target master node's node identifier, then the first proposal's verification result is determined to be unsuccessful. It is understandable that the validity verification process for each round of proposals in the blockchain system is the same; for example, the validity verification process for the first and second proposals is identical.

[0184] Step S302: If the proposal verification result indicates that the verification is successful, then execute the transaction in the first proposal and determine the execution scope of the first transaction of the first blockchain node.

[0185] Specifically, if the proposal verification result indicates that the verification is successful, the first blockchain node can execute all the transactions it is capable of executing within a pre-set valid time period, broadcasting its approval of the block in the first proposal through voting. The pre-set valid time period can be implemented using a timer, which can be started when the first blockchain node enters the pre-voting phase and begins to execute transactions serially. The time period from the start to the end of this timer can be called the transaction execution period.

[0186] It should be understood that all blockchain nodes in the consensus committee have the same pre-set effective duration when executing transactions in the first proposal. Different blockchain nodes may receive the first proposal at different times due to factors such as network speed and hardware performance; that is, the time when each blockchain node starts its timer may differ, and therefore the transaction execution time periods for each blockchain node may also differ. For example, assuming the pre-set effective duration is 1 minute, the transaction execution time period for blockchain node n1 could be 10:00-10:01, and the transaction execution time period for blockchain node n2 could be 10:01-10:02.

[0187] When the first proposal received by the first blockchain node is a valid proposal, the transaction list in the first proposal can be obtained; the transaction execution time period of the first blockchain node is determined, and the transactions in the transaction list are executed within the transaction execution time period to obtain the transaction execution information of all transactions executed by the first blockchain node; the executed transactions are added to the executed transaction set of the first blockchain node; and the first transaction execution range of the first blockchain node is determined based on the number of transactions in the executed transaction set.

[0188] In this context, the executed transaction set consists of transactions successfully executed by the first blockchain node, and the number of transactions in the executed transaction set is less than or equal to the number of transactions in the transaction list. The first transaction execution range can be used to represent all transactions successfully executed by the first blockchain node. It is understandable that when the blockchain system uses a serial deterministic scheduling processing model, each blockchain node in the consensus committee can execute transactions sequentially according to the order of transactions in the transaction list. Therefore, the first transaction execution range can be represented by the maximum number of transactions executed by the first blockchain node.

[0189] For example, if the transaction list includes 5 transactions, namely transaction tx1, transaction tx2, transaction tx3, transaction tx4, and transaction tx5, and the maximum number of transactions completed by the first blockchain node is 3, the first transaction execution range of the first blockchain node can be represented as 3 (or it can be represented as tx3, etc.), indicating that the transactions completed by the first blockchain node are transactions tx1 to tx3.

[0190] Step S303: Based on the first transaction execution scope, generate the first voting information of the first blockchain node for the first proposal, and broadcast the first voting information of the first blockchain node in the blockchain system.

[0191] Specifically, the first blockchain node can perform hash calculations on transactions within the first transaction execution scope to obtain the first block hash corresponding to the first proposal; use the first blockchain node's private key to sign the first block hash and the first transaction execution scope to obtain the first blockchain node's node signature; combine the first block hash, the first transaction execution scope, and the node signature to form the first blockchain node's first voting information for the first proposal; and broadcast the first blockchain node's first voting information in the blockchain system so that all blockchain nodes in the consensus committee can obtain the first blockchain node's first voting information.

[0192] The first voting information can refer to the voting information generated by each blockchain node in the consensus committee when it casts its first vote on the first proposal; for example, the voting information generated during the pre-voting stage of the first proposal. In this embodiment, the voting information generated by any blockchain node in the consensus committee when it casts its first vote on the first proposal can be referred to as the first voting information.

[0193] The first block hash refers to the block hash value obtained by the first blockchain node through hashing all transactions executed during the pre-voting phase of the first proposal. The block hash calculated when the first blockchain node votes on the first proposal for the first time can also be called the first block hash. The calculation method for the first block hash may include, but is not limited to: ① Calculating the transaction hash value corresponding to each transaction within the execution scope of the first transaction, constructing a Merkle tree based on the transaction hash value corresponding to each transaction, and using the root of the Merkle tree as the first block hash. For example, assuming the execution scope of the first transaction includes transactions tx1, tx2, tx3, and tx4, then the transaction hash value 1 for transaction tx1, the transaction hash value 2 for transaction tx2, the transaction hash value 3 for transaction tx3, and the transaction hash value 4 for transaction tx4 can be calculated. Furthermore, a hash operation can be performed on transaction hash values ​​1 and 2 to obtain a joint hash value 12; and a hash operation can be performed on transaction hash values ​​3 and 4 to obtain a joint hash value 34. Continue hashing the combined hash value 12 and combined hash value 34 to obtain the combined hash value 1234, which can be used as the hash of the first block.

[0194] ② The local execution information of each transaction within the first transaction execution scope can be concatenated to obtain concatenated execution information; a hash operation can be performed on this concatenated execution information to obtain the first block hash; the local execution information here can refer to the execution information of the first blockchain node for transactions within the first transaction execution scope. For example, assuming the first transaction execution scope includes transactions tx1, tx2, tx3, and tx4, the local execution information of transactions tx1, tx2, tx3, and tx4 can be concatenated to obtain concatenated execution information, and a hash operation can be performed on this concatenated execution information to obtain the first block hash.

[0195] The above are just two methods for calculating block hashes listed in the embodiments of this application. In addition to the two methods mentioned above, other methods can also be used to calculate block hashes. The embodiments of this application do not limit the method of calculating block hashes.

[0196] Hash operations are implemented using hash algorithms, which can be algorithms that convert input data of arbitrary length into output data of fixed length. The hash algorithms used in the embodiments of this application may include, but are not limited to, MD5 (Message Digest Algorithm), SHA (Secure Hash Algorithm)-224, SHA-256, SHA-384, SHA-512, etc.

[0197] Each blockchain node in a blockchain system possesses a unique key pair, which includes a public key and a private key. The public key is publicly available within the blockchain system, while the private key is kept secret by the blockchain node itself. After calculating the hash of the first block, the first blockchain node uses its own private key (which can be referred to as the node private key for ease of understanding) to sign the hash of the first block and the execution scope of the first transaction, obtaining the node signature of the first blockchain node. This node signature can be used to verify the source and integrity of the first voting information, such as verifying whether the first voting information containing the hash of the first block and the execution scope of the first transaction has been tampered with during transmission.

[0198] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the content of a first voting information provided in an embodiment of this application. For example... Figure 6 As shown, the first voting information 30a may include the block hash 30b, the transaction execution scope 30c, and the signature 30d. For example, when the first voting information 30a is the first voting information generated by the first blockchain node in making its first vote on the first proposal, the block hash 30b can be the aforementioned first block hash, the transaction execution scope 30c can be the aforementioned first transaction execution scope, and the signature 30d can be the node signature of the first blockchain node on the first block hash and the first transaction execution scope.

[0199] Step S304: Obtain first voting information from at least two blockchain nodes regarding the first proposal; generate second voting information from the first blockchain node regarding the first proposal based on the first voting information from the at least two blockchain nodes; and broadcast the second voting information from the first blockchain node in the blockchain system.

[0200] Specifically, after generating its first vote for the first proposal, each blockchain node in the blockchain system can broadcast it within the system. Therefore, the first blockchain node can receive the first vote broadcast by the second blockchain node for the first proposal. Here, the second blockchain node refers to any remaining blockchain node other than the first blockchain node among at least two other blockchain nodes; the number of second blockchain nodes can be one or more.

[0201] From the first voting information of the second blockchain node, obtain the second transaction execution scope of the second blockchain node; based on the first transaction execution scope and the second transaction execution scope, verify the first voting information of the second blockchain node to obtain the voting verification result corresponding to the first voting information of the second blockchain node.

[0202] The second transaction execution scope can be used to characterize all transactions successfully executed by a second blockchain node. When there are multiple second blockchain nodes, the scope of successfully executed transactions by each second blockchain node during the consensus processing of the first proposal can be called the second transaction execution scope. The second transaction execution scope of each second blockchain node can be the same or different, which is related to the data processing performance of each second blockchain node; the better the data processing performance of a second blockchain node, the larger its second transaction execution scope.

[0203] The voting verification result can refer to the result obtained by the first blockchain node in verifying the first voting information received from each of the second blockchain nodes. This verification result can be either successful or unsuccessful; successful verification indicates that the first voting information received by the first blockchain node from the second blockchain nodes is valid; unsuccessful verification indicates that the first voting information received by the first blockchain node from the second blockchain nodes is invalid.

[0204] If the voting verification result indicates successful verification, the first voting information of the second blockchain node can be added to the voting set. This voting set includes the first voting information of the first blockchain node and the first voting information of the verified second blockchain node. Based on the first voting information in the voting set, the first transaction processing count of the first blockchain node can be determined. Based on the first transaction processing count, the second voting information of the first blockchain node for the first proposal is generated. The first blockchain node can broadcast its second voting information within the blockchain system so that all blockchain nodes in the consensus committee can receive the second voting information of the first blockchain node.

[0205] The second voting information can refer to the voting information generated by each blockchain node in the consensus committee when voting on the first proposal for the second time; for example, the voting information generated during the pre-submission stage of the first proposal. In this embodiment, the voting information generated by any blockchain node in the consensus committee when voting on the first proposal for the second time can be referred to as the second voting information. The first transaction processing quantity can refer to the maximum number of transactions executed by the first blockchain node during the consensus processing of the first proposal.

[0206] It is understandable that when the first blockchain node receives first voting information from multiple second blockchain nodes, it needs to verify the first voting information of each second blockchain node. The verification process for each first voting information is similar. This application embodiment uses any one second blockchain node as an example for illustration, and will not describe them one by one.

[0207] In one feasible implementation, the verification process of the first blockchain node's first voting information for the second blockchain node may include: if the number of transactions within the first transaction execution range is greater than the number of transactions within the second transaction execution range, then candidate execution information corresponding to the second transaction execution range is determined from the transaction execution information corresponding to the first transaction execution range. A hash operation is performed on the candidate execution information to obtain a first block verification hash. If the first block verification hash is equal to the second block hash in the second blockchain node's first voting information, then the voting verification result corresponding to the second blockchain node's first voting information is determined to be verified successfully. If the first block verification hash is not equal to the second block hash in the second blockchain node's first voting information, then the voting verification result corresponding to the second blockchain node's first voting information is determined to be verified unsuccessfully.

[0208] The transaction execution information corresponding to the first transaction execution scope refers to the execution information obtained by the first blockchain node during the consensus processing of the first proposal for each transaction within the first transaction execution scope. Candidate execution information refers to the execution information of transactions within the second transaction execution scope, which is part of the transaction execution information corresponding to the first transaction execution scope. The first block verification hash refers to the block hash corresponding to the transactions within the second transaction execution scope, recalculated by the first blockchain node based on its own transaction execution information. The second block hash refers to the block hash value obtained by each second blockchain node through hashing all transactions executed during the pre-voting phase of the first proposal; the block hash calculated by each second blockchain node when it votes on the first proposal for the first time can be called the second block hash.

[0209] In one feasible implementation, the verification process of the first blockchain node's first voting information for the second blockchain node may include: if the number of transactions within the execution scope of the first transaction is equal to the number of transactions within the execution scope of the second transaction, then comparing the first block hash in the first voting information of the first blockchain node with the second block hash in the first voting information of the second blockchain node. If the first block hash in the first voting information of the first blockchain node is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified successfully. If the first block hash in the first voting information of the first blockchain node is not equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified unsuccessfully.

[0210] In one feasible implementation, the verification process of the first blockchain node's first voting information for the second blockchain node may include: if the number of transactions within the first transaction execution range is less than the number of transactions within the second transaction execution range, then a difference transaction is executed between the first and second transaction execution ranges to obtain the execution information of the difference transaction. A hash operation is performed on the execution information of the difference transaction and the transaction execution information corresponding to the first transaction execution range to obtain a second block verification hash. If the second block verification hash is equal to the second block hash in the second blockchain node's first voting information, then the voting verification result corresponding to the second blockchain node's first voting information is determined to be verified successfully. If the second block verification hash is not equal to the second block hash in the second blockchain node's first voting information, then the voting verification result corresponding to the second blockchain node's first voting information is determined to be verified unsuccessfully.

[0211] Here, a differentiated transaction refers to the transaction that differs between the first and second execution ranges. For example, if the transactions within the first execution range are tx1 to tx4, and the transactions within the second execution range are tx1 to tx5, then the differentiated transaction between the first and second execution ranges is tx5. The second block verification hash refers to the block hash corresponding to the transactions within the second execution range, recalculated by the first blockchain node based on its own transaction execution information and the differentiated transaction execution information.

[0212] In one feasible implementation, the process of determining the first transaction processing quantity may include: if the number of transactions within the second transaction execution range in the voting set is less than or equal to the number of transactions within the first transaction execution range, then the number of transactions within the first transaction execution range is determined as the first transaction processing quantity of the first blockchain node. If the number of transactions within the second transaction execution range in the voting set is greater than the number of transactions within the first transaction execution range, then the maximum number of transactions within the second transaction execution range in the voting set is determined as the first transaction processing quantity of the first blockchain node.

[0213] In other words, for all the first votes in the voting set, the blockchain node with the largest number of transactions within its transaction execution scope (including both the first and second transaction execution scopes) is used as the first transaction processing quantity for that blockchain node. For example, if the voting set includes the first votes from blockchain nodes n1, n2, and n3, and if the number of transactions within the transaction execution scope of blockchain node n1 is 5, the number of transactions within the transaction execution scope of blockchain node n2 is 4, and the number of transactions within the transaction execution scope of blockchain node n3 is 4, then 5 can be used as the first transaction processing quantity.

[0214] The second voting information of the first blockchain node may include, but is not limited to: updating the first block hash in the first voting information of the first blockchain node according to the transaction indicated by the first transaction processing quantity to obtain the third block hash; and generating the second voting information of the first blockchain node for the first proposal according to the first transaction processing quantity and the third block hash.

[0215] The third block hash refers to the block hash obtained by the first blockchain node through hashing all transactions executed during the pre-submission phase of the first proposal; the block hash value calculated when the first blockchain node votes on the first proposal for the second time is called the third hash value. The second voting information can refer to the voting information generated by each blockchain node in the consensus committee when voting on the first proposal for the second time; for example, the voting information generated during the pre-submission phase of the first proposal. In this embodiment, the voting information generated by any blockchain node in the consensus committee when voting on the first proposal for the second time can be referred to as the second voting information.

[0216] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating the content of a second voting information provided in an embodiment of this application. For example... Figure 7 As shown, the second voting information 40a may include the block hash 40b, the transaction processing quantity 40c, and the signature 40d. For example, when the second voting information 40a is the second voting information generated by the first blockchain node in making a second vote on the first proposal, the block hash 40b can be the aforementioned third block hash, the transaction processing quantity 40c can be the aforementioned first transaction processing quantity, and the signature 40d can be the node signature of the first blockchain node on the third block hash and the first transaction processing quantity.

[0217] Step S305: Obtain the second voting information of at least two blockchain nodes for the first proposal, and determine the proposal consensus result of the first proposal based on the second voting information of at least two blockchain nodes.

[0218] Specifically, after generating a second vote for the first proposal, each blockchain node in the blockchain system can broadcast it within the blockchain system. Therefore, the first blockchain node can receive the second vote for the first proposal broadcast by the second blockchain node; that is, by combining its own second vote, the first blockchain node can obtain the second votes from at least two blockchain nodes in the consensus committee.

[0219] The first blockchain node can count the number of votes in favor of the first proposal in the second voting information of at least two blockchain nodes; if the number of votes in favor of the first proposal is greater than the voting threshold, the consensus result of the first proposal can be determined as a successful consensus, and the block in the first proposal can be added to the blockchain; if the number of votes in favor of the first proposal is less than or equal to the voting threshold, the consensus result of the first proposal can be determined as a failed consensus.

[0220] In one feasible implementation, the first blockchain node can classify and statistically analyze the second voting information from at least two blockchain nodes to obtain the number of nodes for each type of second voting information, and determine the largest number of nodes as the number of affirmative votes for the first proposal. The process of classifying and statistically analyzing the second voting information can be found in [reference needed]. Figure 3 The classification and statistical process described in step S101 of the corresponding embodiment will not be repeated here.

[0221] Step S306: If the consensus result of the proposal indicates that the consensus has failed, then obtain the number of transactions processed by the first blockchain node for the first proposal.

[0222] Step S307: Based on the first transaction processing quantity, obtain the set of processed transactions of the first blockchain node in the first proposal, and generate the second proposal based on the set of processed transactions.

[0223] Step S308: Broadcast the second proposal in the blockchain system so that at least two blockchain nodes in the blockchain system can reach a consensus on the second proposal.

[0224] The specific implementation process of steps S306 to S308 can be found in [reference needed]. Figure 3 and Figure 4 The descriptions of each step in the corresponding embodiments will not be repeated here.

[0225] Please see Figure 8 , Figure 8This is a schematic diagram illustrating the generation process of first voting information for a first proposal, as provided in an embodiment of this application. It is understood that the processing flow (i.e., the generation process of first voting information) for the first proposal by each blockchain node in the consensus committee is similar. The following description uses the first blockchain node (the slave node of the first proposal) as an example to illustrate the generation process of first voting information. Figure 8 As shown, the process of generating the first voting information may include the following steps S401 to S406:

[0226] Step S401: parse the first proposal, verify the validity (reasonableness) of the first proposal.

[0227] Specifically, after receiving the first proposal broadcast by the target master node (the blockchain node that created the first proposal), the first blockchain node can verify the validity of the first proposal. The validity verification process of the first proposal can be found in [reference needed]. Figure 5 The description of step S301 in the corresponding embodiment will not be repeated here. When the first proposal is a valid proposal, the subsequent steps can continue; when the first proposal is an invalid proposal, the first proposal can be discarded.

[0228] Step S402: Obtain the transaction list (which can be denoted as Txs) from the first proposal.

[0229] Specifically, when the first blockchain node receives a valid proposal, it can obtain the transaction list Txs from the first proposal. The transaction list Txs can refer to the set of transactions in the first proposal, sorted according to their submission time.

[0230] Step S403: Execute the transactions in the transaction list Txs one by one according to the serial strategy.

[0231] Specifically, the first blockchain node can start a transaction execution timer. After the timer starts, it can execute the transactions in the transaction list Txs one by one according to a serial strategy, obtaining the execution information of each transaction in the transaction list Txs. The execution information of each transaction executed by the first blockchain node can be used as the transaction execution information of the first blockchain node for the first proposal.

[0232] The transaction execution timer can be used to set the duration for the first blockchain node to execute transactions in the first proposal. Each blockchain node in the consensus committee can start the transaction execution timer when executing transactions in the first proposal, and the duration set for the transaction execution timer of each blockchain node is the same. The serial strategy means that each blockchain node executes transactions in the transaction list Txs in the order in which the transactions are arranged in the transaction list Txs.

[0233] Step S404: After the transaction is completed, add it to the set of executed transactions (which can be denoted as CTxs).

[0234] Specifically, after the transaction execution timer is started, all transactions completed by the first blockchain node can be added to the executed transaction set CTxs. In other words, the executed transaction set CTxs includes all transactions completed by the first blockchain node when the transaction execution timer stops; the number of transactions in the executed transaction set CTxs is less than or equal to the number of transactions in the transaction list Txs.

[0235] Step S405: Calculate the first block hash (which can be denoted as BlockHash11) based on the transactions in the executed transaction set CTXs.

[0236] Specifically, the first blockchain node can perform a hash operation on the transactions in the executed transaction set CTXs to obtain the first block hash, BlockHash11. The detailed calculation process for the first block hash, BlockHash11, can be found in [link to documentation]. Figure 5 The relevant descriptions in step S303 of the corresponding embodiment will not be repeated here.

[0237] Step S406: Generate the first voting information for the first proposal.

[0238] Specifically, the first transaction execution range (which can be denoted as TxRange11) of the first blockchain node can be determined based on the number of transactions in the executed transaction set CTXs. The first transaction execution range TxRange11 and the first block hash BlockHash11 are signed using the first blockchain node's private key to obtain the first blockchain node's node signature Sign11. The aforementioned first transaction execution range TxRange11, first block hash BlockHash11, and node signature Sign11 can serve as the first voting information generated by the first blockchain node for the first proposal, such as... Figure 6 The first voting information 30a is shown.

[0239] It's understandable that transactions in the transaction list Txs are executed one by one in a sequential strategy. That is, each blockchain node in the consensus committee starts executing transactions from the first transaction in Txs. After the first transaction is completed, it continues executing the second transaction, and so on, until the transaction execution timer expires. Therefore, the first transaction execution range TxRange11 can also be represented by the number of transactions in the executed transaction set CTxs. The number of transactions in the executed transaction set CTxs can be considered as the number of transactions within the first transaction execution range TxRange11, and this number can be denoted as TxEnd11. In other words, the first transaction execution range can be represented as either TxRange11 or TxEnd11.

[0240] After generating its first vote, the first blockchain node can broadcast its generated first vote to other blockchain nodes (the second blockchain node). Similarly, the first blockchain node can also receive the first vote broadcast by the second blockchain node.

[0241] Please see Figure 9 , Figure 9 This is a schematic diagram illustrating the generation process of second voting information for a first proposal, provided in an embodiment of this application. It is understood that the processing flow (i.e., the generation process of second voting information) for the second vote on the first proposal by each blockchain node in the consensus committee is similar. The following description uses the first blockchain node as an example to illustrate the generation process of second voting information. Figure 9 As shown, the process of generating the second voting information may include the following steps S501 to S511:

[0242] Step S501: parse the first voting information v1 of the second blockchain node, and obtain the second block hash (which can be denoted as BlockHash12) and the second transaction execution range (which can be denoted as TxEnd12) in the first voting information v1.

[0243] This application embodiment uses the first voting information (e.g., first voting information v1) of any second blockchain node as an example for illustration. Specifically, after receiving the first voting information v1, the first blockchain node can parse the first voting information v1 to obtain the second block hash BlockHash12 and the second transaction execution range TxEnd12 from the first voting information v1.

[0244] Step S502: Determine the size relationship between the first transaction execution range TxEnd11 and the second transaction execution range TxEnd12.

[0245] Specifically, when the first transaction execution range TxEnd11 and the second transaction execution range TxEnd12 are the same, step S503 can be continued; when the second transaction execution range TxEnd12 is less than the first transaction execution range TxEnd11, steps S504 to S505 can be continued; when the second transaction execution range TxEnd12 is greater than the first transaction execution range TxEnd11, steps S506 to S508 can be continued.

[0246] Step S503: Determine whether the hash of the first block, BlockHash11, and the hash of the second block, BlockHash12, are equal.

[0247] Specifically, when the execution range of the first transaction, TxEnd11, and the execution range of the second transaction, TxEnd12, are the same, the relationship between the first block hash, BlockHash11, and the second block hash, BlockHash12, is further determined. If the first block hash, BlockHash11, and the second block hash, BlockHash12 are equal, then it can be determined that the first voting information v1 has passed the verification of the first blockchain node. That is, the voting verification result of the first voting information v1 indicates that the verification has passed, and the first voting information v1 can be added to the voting set.

[0248] If the first block hash BlockHash11 and the second block hash BlockHash12 are not equal, then it can be determined that the first voting information v1 has not passed the verification of the first blockchain node. That is, the voting verification result of the first voting information v1 indicates that the verification has failed, and the first voting information v1 can be discarded.

[0249] Step S504: Calculate the first block verification hash (which can be denoted as BlockHash13) based on the transaction execution information of the first blockchain node and the second transaction execution range TxEnd12.

[0250] Specifically, when the second transaction execution range TxEnd12 is less than the first transaction execution range TxEnd11, the first blockchain node can obtain the candidate execution information corresponding to the second transaction execution range TxEnd12 from the locally cached transaction execution information; based on the candidate execution information, the block hash is recalculated, namely the first block verification hash BlockHash13.

[0251] Step S505: Determine whether the hash of the second block, BlockHash12, is equal to the verification hash of the first block, BlockHash13.

[0252] Specifically, if the hash of the second block, BlockHash12, is equal to the verification hash of the first block, BlockHash13, then it can be determined that the verification result of the first voting information v1 indicates that the verification has passed, and the first voting information v1 can be added to the voting set.

[0253] If the hash of the second block, BlockHash12, is not equal to the verification hash of the first block, BlockHash13, then it can be determined that the verification result of the first voting information v1 indicates that the verification failed, and the first voting information v1 can be discarded.

[0254] Step S506: Based on the first transaction execution range TxEnd11, execute the difference transaction between the first transaction execution range TxEnd11 and the second transaction execution range TxEnd12.

[0255] Specifically, when the second transaction execution range TxEnd12 is greater than the first transaction execution range TxEnd11, the difference between the first transaction execution range TxEnd11 and the second transaction execution range TxEnd12 can be executed to obtain the execution information of the difference transaction.

[0256] Understandably, when the first blockchain node executes a differential transaction, it can use a timer to impose a time limit. If the differential transaction is completed within the time limit specified by the timer, the validity of the first voting information v1 can be determined. If the differential transaction is not completed within the time limit specified by the timer, the first voting information v1 can be discarded, indicating that the first blockchain node does not recognize the first voting information v1.

[0257] Step S507: Calculate the second block verification hash (which can be denoted as BlockHash14) based on the execution information of the differential transaction and the transaction execution information of the first blockchain node.

[0258] Specifically, based on the execution information of the differential transactions and the transaction execution information of the first blockchain node, the block hash corresponding to the second transaction execution range TxEnd12, i.e. the second block verification hash BlockHash14, can be recalculated.

[0259] Step S508: Determine whether the second block hash BlockHash12 is equal to the second block verification hash BlockHash14.

[0260] Specifically, if the second block hash BlockHash12 is equal to the second block verification hash BlockHash14, then it can be determined that the verification result of the first voting information v1 indicates that the verification is successful, and the first voting information v1 can be added to the voting set.

[0261] If the second block hash BlockHash12 is not equal to the second block verification hash BlockHash14, then it can be determined that the verification result of the first voting information v1 indicates that the verification failed, and the first voting information v1 can be discarded.

[0262] Step S509: Summarize the first voting information in the voting set.

[0263] Specifically, the first blockchain node can collect the first voting information from each participating blockchain node within a pre-set time period. The pre-set time period can be implemented using a timer or other methods; this application does not limit this. Upon reaching the pre-set time period, the first blockchain can summarize the first voting information in the voting set, such as determining which first voting information has the largest transaction execution scope. Here, the transaction execution scope of the first voting information can be the first transaction execution scope of the first blockchain node or the second transaction execution scope of the second blockchain node.

[0264] Step S510: Update the first transaction execution scope TxEnd11 in the local cache of the first blockchain node.

[0265] Specifically, based on all the first voting information in the voting set, the execution range TxEnd11 of the first transaction in the local cache of the first blockchain node can be updated to obtain the number of first transactions processed (which can be denoted as TxEnd21). The process for determining the number of first transactions processed, TxEnd21, can be found in [link to documentation]. Figure 5 The relevant descriptions in step S304 of the corresponding embodiment will not be repeated here.

[0266] Step S511: Generate the second voting information for the first proposal.

[0267] Specifically, the block hash (which can be called the third block hash BlockHash21) of the transaction indicated by the first transaction processing quantity TxEnd21 can be calculated. The first blockchain node's private key is then used to sign the first transaction processing quantity TxEnd21 and the third block hash BlockHash21, resulting in the first blockchain node's node signature Sign21. The aforementioned first transaction processing quantity TxEnd21, third block hash BlockHash21, and node signature Sign21 can serve as the second voting information generated by the first blockchain node for the first proposal, such as... Figure 7 The second voting information 40a is shown.

[0268] After the first blockchain node generates the second voting information, it can broadcast its generated second voting information to other blockchain nodes (the second blockchain nodes). Similarly, the first blockchain node can also receive the second voting information broadcast by the second blockchain nodes. The first blockchain node can determine whether the first proposal has reached consensus based on the second voting information it has received. For the specific determination process, please refer to [link to relevant documentation]. Figure 5 The relevant descriptions in step S305 of the corresponding embodiment will not be repeated here.

[0269] In this embodiment, when all transactions in the current proposal (e.g., the first proposal) are unprocessed, the content of the two voting information (first voting information and second voting information) of the first proposal can be adjusted during the consensus processing of the first proposal. The scope of transaction execution (number of transactions processed) can be added to both voting information to indicate the end position of each blockchain node when executing transactions during the consensus processing, which helps to accelerate the voting verification between blockchain nodes. When the consensus of the first proposal fails, although the transactions in the first proposal ultimately do not reach consensus, each blockchain node has already executed all or part of the transactions in the first proposal. Therefore, in the next round of proposals, successfully executed transactions can be retained as much as possible, such as creating the next round of proposals (the second proposal) based on these successfully executed transactions. During the consensus processing of the second proposal, each blockchain node does not need to repeatedly execute the transactions in the second proposal, and all executed transactions are successfully executed, which can improve the consensus success rate and efficiency of the proposal.

[0270] Please see Figure 10 , Figure 10 This is a schematic diagram of a consensus processing flow in a blockchain system provided in an embodiment of this application. Figure 10 As shown, taking a consensus committee containing four blockchain nodes as an example, the consensus processing flow of a BFT-type consensus algorithm is described. These four blockchain nodes are blockchain node 1, blockchain node 2, blockchain node 3, and blockchain node 4. Among them, blockchain node 1 is the master node of the previous round of proposals (the first proposal), and blockchain node 2 is the master node of the next round of proposals (the second proposal).

[0271] Blockchain node 1 can retrieve a batch of transactions from the transaction pool, generate a first proposal, and broadcast the first proposal so that blockchain nodes 2, 3, and 4 can all access it. Each blockchain node can execute the transactions in the first proposal according to a serial deterministic scheduling processing model (serial strategy), generating its own block hash; for example, the block hash generated by blockchain node 1 can be called the first block hash, and the block hashes generated by blockchain nodes 2, 3, and 4 can be called the second block hash. Each blockchain node can generate first voting information based on its own generated block hash, the number of transactions executed, and other information, and broadcast its own first voting information, which can be considered as broadcasting the first voting result of the first proposal.

[0272] Each blockchain node can aggregate the initial voting information it receives, conduct a second vote on the first proposal, generate second voting information, and broadcast its own generated second voting information. This can be considered as broadcasting the second voting result of the first proposal. The process of generating the second voting information can be found in [link to documentation]. Figure 3 The description in step S304 of the corresponding embodiment.

[0273] Each blockchain node can aggregate the second vote information it receives and determine the consensus result of the first proposal based on this information. When the consensus result of the first proposal indicates successful consensus, the transactions in the first proposal can be submitted to the blockchain as a block. When the consensus result of the first proposal indicates failed consensus, the transactions in the first proposal can be rolled back locally, and the consensus information of the first proposal can be temporarily cached locally. Local rollback can refer to each blockchain node reversing the execution of already executed transactions locally, restoring the system to its state before the transactions were executed.

[0274] If the consensus result of the first proposal indicates consensus failure, a next master node, such as blockchain node 2, can be elected from the consensus committee to enter the consensus processing flow for the next round of proposals. Blockchain node 2 can obtain the number of transactions it approved for processing (e.g., the first transaction processing count) from the consensus information of the first proposal (the consensus information of the previous round), and create the next round of proposals (such as the second proposal) based on the completed transactions indicated by the transaction processing count. Blockchain node 2 can broadcast the second proposal so that blockchain nodes 1, 3, and 4 can all obtain the second proposal.

[0275] Each blockchain node can vote on the second proposal based on the consensus information of the first proposal cached locally, generating a third vote. This first vote refers to determining whether to approve the second proposal based on the locally cached consensus information. If the second proposal is approved, the generated third vote is a "yes" vote; if it is disapproved, it is a "no" vote. Each blockchain node can broadcast its generated third vote, which can be considered the first voting result for the second proposal. The process of generating the third vote can be found in [link to documentation]. Figure 4 The descriptions in the corresponding embodiments will not be repeated here.

[0276] Each blockchain node can aggregate the third voting information it receives, conduct a second vote on the second proposal, generate a fourth voting message, and broadcast its own generated fourth voting message, which can be considered the second voting result of the second proposal. Furthermore, each blockchain node can aggregate the fourth voting information it receives and determine the proposal consensus result of the second proposal based on the fourth voting information. When the proposal consensus result of the second proposal indicates successful consensus, the transactions in the second proposal can be submitted to the blockchain in the form of blocks. When the proposal consensus result of the second proposal indicates failed consensus, the transactions in the second proposal can be rolled back locally, and the consensus information of the second proposal can be temporarily cached locally.

[0277] In this embodiment of the application, in the event that the consensus of the previous round of proposals (the first proposal) fails, the number of transactions recognized by each blockchain node can be preserved to the greatest extent possible, ensuring the normal execution of the next round of proposals (the second proposal) and improving the consensus efficiency of the blockchain system.

[0278] It is understood that, in the specific implementation of this application, the information data submitted to the blockchain system may involve user transaction data, network address, account, account balance and other related information. When the above embodiments of this application are applied to specific products or technologies, permission or consent from relevant users or institutions is required, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant regions.

[0279] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a data processing device in a blockchain system provided in an embodiment of this application. Figure 1 Understandably, the data processing device 1 in this blockchain system can be applied to the first blockchain node, which can be any blockchain node in the consensus committee. For example... Figure 11As shown, the data processing device 1 in the blockchain system may include: a first acquisition module 11, a second acquisition module 12, a proposal generation module 13, and a proposal broadcasting module 14;

[0280] The first acquisition module 11 is used to acquire the consensus result of the first proposal;

[0281] The second acquisition module 12 is used to acquire the first transaction processing quantity of the first blockchain node for the first proposal if the consensus result of the proposal indicates that the consensus has failed.

[0282] The proposal generation module 13 is used to obtain the set of processed transactions of the first blockchain node in the first proposal based on the first transaction processing quantity, and generate a second proposal based on the set of processed transactions.

[0283] The proposal broadcasting module 14 is used to broadcast the second proposal in the blockchain system so that at least two blockchain nodes in the blockchain system can reach a consensus on the second proposal.

[0284] In one or more embodiments, the first acquisition module 11 is configured to perform the following steps:

[0285] Obtain the first proposal, verify its validity, and obtain the proposal verification result.

[0286] If the proposal verification result indicates that the verification is successful, then the transaction in the first proposal is executed, and the execution scope of the first transaction of the first blockchain node is determined;

[0287] Based on the execution scope of the first transaction, the first voting information of the first blockchain node for the first proposal is generated, and the first voting information of the first blockchain node is broadcast in the blockchain system.

[0288] Obtain first voting information from at least two blockchain nodes regarding the first proposal; generate second voting information from the first blockchain node regarding the first proposal based on the first voting information from at least two blockchain nodes; and broadcast the second voting information from the first blockchain node in the blockchain system.

[0289] Obtain the second voting information of at least two blockchain nodes for the first proposal, and determine the consensus result of the first proposal based on the second voting information of at least two blockchain nodes.

[0290] In one or more embodiments, the first acquisition module 11 verifies the validity of the first proposal to obtain the proposal verification result, which is then used to perform the following steps:

[0291] Obtain the master node identifier in the first proposal, and determine the target master node of the first proposal from at least two blockchain nodes according to the master node selection strategy in the blockchain system.

[0292] The validity of the transactions in the first proposal is verified to obtain the transaction verification results corresponding to the first proposal.

[0293] If the transaction verification result indicates that the verification is successful, and the master node identifier is the node identifier of the target master node, then the proposal verification result of the first proposal is determined to be successful.

[0294] If the transaction verification result indicates that the verification failed, or the master node identifier is not the node identifier of the target master node, then the verification result of the first proposal is determined to be that the verification failed.

[0295] In one or more embodiments, if the proposal verification result indicates that the verification is successful, the first acquisition module 11 executes the transaction in the first proposal, determines the execution scope of the first transaction of the first blockchain node, and performs the following steps:

[0296] If the proposal verification result indicates that the verification is successful, then obtain the list of transactions in the first proposal;

[0297] Determine the transaction execution time period for the first blockchain node. Within the transaction execution time period, execute the transactions in the transaction list and add the completed transactions to the executed transaction set of the first blockchain node.

[0298] The first transaction execution scope of the first blockchain node is determined based on the number of transactions in the executed transaction set.

[0299] In one or more embodiments, the first acquisition module 11 generates first voting information of the first blockchain node for the first proposal based on the first transaction execution scope, for use in performing the following steps:

[0300] Perform a hash operation on the transactions within the execution scope of the first transaction to obtain the hash of the first block corresponding to the first proposal;

[0301] The first blockchain node's private key is used to sign the first block hash and the first transaction execution scope to obtain the first blockchain node's node signature.

[0302] The first block hash, the first transaction execution scope, and the node signature are combined to form the first voting information of the first blockchain node for the first proposal.

[0303] In one or more embodiments, the first acquisition module 11 acquires first voting information from at least two blockchain nodes regarding the first proposal, and generates second voting information from the first blockchain nodes regarding the first proposal based on the first voting information from the at least two blockchain nodes, for use in performing the following steps:

[0304] Receive the first vote information for the first proposal broadcast by the second blockchain node, where the second blockchain node refers to the remaining blockchain node other than the first blockchain node among at least two blockchain nodes;

[0305] The second transaction execution scope of the second blockchain node is obtained from the first voting information of the second blockchain node;

[0306] Based on the first and second transaction execution scopes, the first voting information of the second blockchain node is verified to obtain the voting verification result corresponding to the first voting information of the second blockchain node.

[0307] If the voting verification result indicates that the verification is successful, the first voting information of the second blockchain node is added to the voting set; the voting set includes the first voting information of the first blockchain node.

[0308] Based on the first voting information in the voting set, determine the first transaction processing quantity of the first blockchain node;

[0309] Based on the first transaction processing quantity, generate the second voting information of the first blockchain node for the first proposal.

[0310] In one or more embodiments, the first acquisition module 11 verifies the first voting information of the second blockchain node according to the first transaction execution scope and the second transaction execution scope, and obtains the voting verification result corresponding to the first voting information of the second blockchain node, which is used to perform the following steps:

[0311] If the number of transactions within the first execution scope is greater than the number of transactions within the second execution scope, then candidate execution information corresponding to the second execution scope is determined from the transaction execution information corresponding to the first execution scope.

[0312] Perform a hash operation on the candidate execution information to obtain the verification hash of the first block;

[0313] If the first block verification hash is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

[0314] In one or more embodiments, the first acquisition module 11 verifies the first voting information of the second blockchain node according to the first transaction execution scope and the second transaction execution scope, and obtains the voting verification result corresponding to the first voting information of the second blockchain node, which is used to perform the following steps:

[0315] If the number of transactions within the execution scope of the first transaction is equal to the number of transactions within the execution scope of the second transaction, then the first block hash in the first voting information of the first blockchain node is compared with the second block hash in the first voting information of the second blockchain node.

[0316] If the hash of the first block in the first voting information of the first blockchain node is equal to the hash of the second block in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

[0317] In one or more embodiments, the first acquisition module 11 verifies the first voting information of the second blockchain node according to the first transaction execution scope and the second transaction execution scope, and obtains the voting verification result corresponding to the first voting information of the second blockchain node, which is used to perform the following steps:

[0318] If the number of transactions within the first execution scope is less than the number of transactions within the second execution scope, then the difference between the first and second execution scopes is executed to obtain the execution information of the difference.

[0319] The execution information of the differential transactions and the execution information of the transactions corresponding to the execution scope of the first transaction are hashed to obtain the verification hash of the second block;

[0320] If the second block verification hash is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

[0321] In one or more embodiments, the first acquisition module 11 determines the first transaction processing quantity of the first blockchain node based on the first voting information in the voting set, and performs the following steps:

[0322] If the number of transactions within the second transaction execution range in the voting set is less than or equal to the number of transactions within the first transaction execution range, then the number of transactions within the first transaction execution range is determined as the first transaction processing number of the first blockchain node;

[0323] If the number of transactions within the second transaction execution range in the voting set is greater than the number of transactions within the first transaction execution range, then the maximum number of transactions within the second transaction execution range in the voting set will be determined as the first transaction processing number of the first blockchain node.

[0324] In one or more embodiments, the first acquisition module 11 generates second voting information of the first blockchain node for the first proposal based on the first transaction processing quantity, for use in performing the following steps:

[0325] Based on the transaction indicated by the first transaction processing quantity, the first block hash in the first voting information of the first blockchain node is updated to obtain the third block hash;

[0326] Based on the first transaction processing quantity and the third block hash, the second voting information of the first blockchain node for the first proposal is generated.

[0327] In one or more embodiments, the first acquisition module 11 determines the proposal consensus result of the first proposal based on the second voting information of at least two blockchain nodes, and performs the following steps:

[0328] In the second voting information from at least two blockchain nodes, count the number of votes in favor of the first proposal;

[0329] If the number of votes in favor exceeds the voting threshold, the consensus result of the first proposal is determined to be a successful consensus.

[0330] If the number of votes in favor is less than or equal to the voting threshold, then the consensus result of the first proposal is determined to be a consensus failure.

[0331] In one or more embodiments, the proposal generation module 13 obtains the set of processed transactions of the first blockchain node from the first proposal based on the first transaction processing quantity, and generates a second proposal based on the set of processed transactions, for performing the following steps:

[0332] According to the order of transactions in the transaction list of the first proposal, the transactions in the transaction list are added to the processed transaction set of the first blockchain node; the number of transactions in the processed transaction set is equal to the number of transactions processed in the first proposal.

[0333] The first transaction processing quantity and the transactions in the processed transaction set are encapsulated into a second proposal; the second proposal includes the third block hash in the second voting information of the first blockchain node.

[0334] Please see Figure 12 , Figure 12 This is a schematic diagram of the structure of a data processing device in a blockchain system provided in an embodiment of this application. Figure 2 Understandably, the data processing device 2 in this blockchain system can be applied to a second blockchain node, which can be a blockchain node in the consensus committee other than the first blockchain node. For example... Figure 12 As shown, the data processing device 2 in the blockchain system may include: a proposal receiving module 21 and a consensus processing module 22;

[0335] The proposal receiving module 21 is used to receive the second proposal broadcast by the first blockchain node; the second proposal is generated based on the set of processed transactions of the first blockchain node, and the set of processed transactions includes the transactions obtained in the first proposal based on the number of first transactions processed by the first blockchain node for the first proposal when the consensus result of the first proposal indicates that the consensus has failed;

[0336] Consensus processing module 22 is used to process the second proposal.

[0337] In one or more embodiments, the second proposal includes a third block hash; the consensus processing module 22 is used to perform the following steps:

[0338] Get the number of first transactions processed in the second proposal, and get the number of second transactions processed by the second blockchain node for the first proposal;

[0339] Based on the first and second transaction processing counts, the hash of the third block in the second proposal is verified to obtain the hash verification result;

[0340] If the hash verification result indicates that the verification passed, then the approval vote information for the second proposal is generated;

[0341] If the hash verification result indicates that the verification failed, then a second proposal's opposing vote is generated.

[0342] According to one embodiment of this application, the steps involved in the data processing method in the blockchain system described above can be derived by... Figure 11 The data processing device 1 in the blockchain system shown, and Figure 12 The data processing unit 2 in the blockchain system shown is used to execute this process. For example, Figure 3 The step S101 shown can be performed by Figure 11 The first acquisition module 11 shown is used to execute this. Figure 3 The step S102 shown can be performed by Figure 11 The second acquisition module 12 shown is used to execute this. Figure 3 The step S103 shown can be performed by Figure 11 The proposal generation module 13 shown is used to execute this. Figure 3 The step S104 shown can be performed by Figure 11 The proposal broadcast module 14 shown is used to execute, etc.

[0343] According to one embodiment of this application, Figure 11 The data processing device 1 in the blockchain system shown, and Figure 12The modules in the data processing device 2 of the blockchain system shown can be individually or entirely merged into one or more modules, or some of these modules can be further divided into at least two functionally smaller modules to achieve the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can also be implemented by at least two modules, or the function of at least two modules can be implemented by one module. In other embodiments of this application, Figure 11 The data processing device 1 in the blockchain system shown, and Figure 12 The data processing device 2 in the blockchain system shown may also include other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented by at least two modules working together.

[0344] In this embodiment, when all transactions in the current proposal (e.g., the first proposal) are unprocessed, the content of the two voting information (first voting information and second voting information) of the first proposal can be adjusted during the consensus processing of the first proposal. The scope of transaction execution (number of transactions processed) can be added to both voting information to indicate the end position of each blockchain node when executing transactions during the consensus processing, which helps to accelerate the voting verification between blockchain nodes. When the consensus of the first proposal fails, although the transactions in the first proposal ultimately do not reach consensus, each blockchain node has already executed all or part of the transactions in the first proposal. Therefore, in the next round of proposals, successfully executed transactions can be retained as much as possible, such as creating the next round of proposals (the second proposal) based on these successfully executed transactions. During the consensus processing of the second proposal, each blockchain node does not need to repeatedly execute the transactions in the second proposal, and all executed transactions are successfully executed, which can improve the consensus success rate and efficiency of the proposal.

[0345] Please see Figure 13 , Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 13As shown, the computer device 1000 can be a terminal device or a server; this is not a limitation. For ease of understanding, this application uses the computer device as a terminal device as an example. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 13 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0346] The network interface 1004 in the computer device 1000 can also provide network communication functions, and the optional user interface 1003 can also include a display screen and a keyboard. Figure 13 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0347] Obtain the consensus result of the first proposal;

[0348] If the consensus result of the proposal indicates that the consensus has failed, then obtain the number of transactions processed by the first blockchain node for the first proposal;

[0349] Based on the first transaction processing count, obtain the set of processed transactions of the first blockchain node in the first proposal, and generate the second proposal based on the set of processed transactions;

[0350] The second proposal is broadcast in the blockchain system so that at least two blockchain nodes in the blockchain system can reach a consensus on the second proposal.

[0351] Alternatively, processor 1001 can be used to call the device control application stored in memory 1005 to achieve:

[0352] Receive the second proposal broadcast by the first blockchain node; the second proposal is generated based on the set of processed transactions of the first blockchain node, the set of processed transactions includes the transactions obtained in the first proposal based on the number of transactions processed by the first blockchain node for the first proposal when the consensus result of the first proposal indicates that the consensus has failed;

[0353] The second proposal was processed through consensus.

[0354] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figures 3 to 5 , Figure 8 as well as Figure 9 The description of the data processing method in the blockchain system in any of the corresponding embodiments can also be performed as described above. Figure 11 The corresponding embodiment refers to the data processing device 1 in the blockchain system, or Figure 12 The description of the data processing device 2 in the blockchain system in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0355] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the data processing device 1 or the data processing device 2 in the blockchain system mentioned above. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figures 3 to 5 , Figure 8 as well as Figure 9 The description of the data processing method in the blockchain system in any corresponding embodiment is therefore not repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed and executed on a single computer device, or on multiple computer devices located in one location, or on multiple computer devices distributed across multiple locations and interconnected via a communication network. These multiple computer devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0356] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, causing the computer device to perform the aforementioned actions. Figures 3 to 5 , Figure 8 as well as Figure 9 The description of the data processing method in the blockchain system in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0357] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different media content, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0358] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0359] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

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

[0361] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method in a blockchain system, characterized in that, The blockchain system includes at least two blockchain nodes participating in consensus, the at least two blockchain nodes including a first blockchain node, and the method includes: Obtain the consensus result of the first proposal; If the consensus result of the proposal indicates that the consensus has failed, then obtain the first transaction processing count of the first blockchain node for the first proposal; Based on the first transaction processing quantity, obtain the set of processed transactions of the first blockchain node in the first proposal, and generate a second proposal based on the set of processed transactions; The second proposal is broadcast in the blockchain system so that at least two blockchain nodes in the blockchain system can reach a consensus on the second proposal.

2. The method according to claim 1, characterized in that, The process of obtaining the consensus result of the first proposal includes: Obtain the first proposal, verify the validity of the first proposal, and obtain the proposal verification result of the first proposal; If the proposal verification result indicates that the verification is successful, then the transaction in the first proposal is executed, and the execution scope of the first transaction of the first blockchain node is determined; Based on the first transaction execution scope, the first voting information of the first blockchain node for the first proposal is generated, and the first voting information of the first blockchain node is broadcast in the blockchain system; Obtain first voting information from at least two blockchain nodes regarding the first proposal; generate second voting information from the first blockchain node regarding the first proposal based on the first voting information from the at least two blockchain nodes; and broadcast the second voting information from the first blockchain node in the blockchain system. Obtain the second voting information of the at least two blockchain nodes regarding the first proposal, and determine the consensus result of the first proposal based on the second voting information of the at least two blockchain nodes.

3. The method according to claim 2, characterized in that, The step of validating the first proposal to obtain the proposal verification result includes: Obtain the master node identifier in the first proposal, and determine the target master node of the first proposal from at least two blockchain nodes according to the master node selection strategy in the blockchain system. The validity of the transactions in the first proposal is verified to obtain the transaction verification result corresponding to the first proposal. If the transaction verification result indicates that the verification is successful, and the master node identifier is the node identifier of the target master node, then the proposal verification result of the first proposal is determined to be successful. If the transaction verification result indicates that the verification failed, or if the master node identifier is not the node identifier of the target master node, then the proposal verification result of the first proposal is determined to be that the verification failed.

4. The method according to claim 2, characterized in that, If the proposal verification result indicates that the verification is successful, then the transaction in the first proposal is executed, and the execution scope of the first transaction of the first blockchain node is determined, including: If the proposal verification result indicates that the verification is successful, then obtain the transaction list in the first proposal; Determine the transaction execution time period of the first blockchain node, execute the transactions in the transaction list within the transaction execution time period, and add the completed transactions to the executed transaction set of the first blockchain node; The first transaction execution scope of the first blockchain node is determined based on the number of transactions in the executed transaction set.

5. The method according to claim 2, characterized in that, The step of generating the first voting information of the first blockchain node for the first proposal based on the first transaction execution scope includes: Perform a hash operation on the transactions within the execution scope of the first transaction to obtain the hash of the first block corresponding to the first proposal; Using the private key of the first blockchain node, the first block hash and the first transaction execution scope are signed to obtain the node signature of the first blockchain node; The first block hash, the first transaction execution scope, and the node signature are combined to form the first voting information of the first blockchain node for the first proposal.

6. The method according to claim 2, characterized in that, The step of obtaining the first voting information of the at least two blockchain nodes regarding the first proposal, and generating the second voting information of the first blockchain nodes regarding the first proposal based on the first voting information of the at least two blockchain nodes, includes: Receive the first vote information for the first proposal broadcast by the second blockchain node, where the second blockchain node refers to the remaining blockchain nodes other than the first blockchain node among the at least two blockchain nodes; The second transaction execution scope of the second blockchain node is obtained from the first voting information of the second blockchain node; Based on the first transaction execution scope and the second transaction execution scope, the first voting information of the second blockchain node is verified to obtain the voting verification result corresponding to the first voting information of the second blockchain node; If the voting verification result indicates that the verification is successful, then the first voting information of the second blockchain node is added to the voting set; the voting set includes the first voting information of the first blockchain node. Based on the first voting information in the voting set, determine the first transaction processing quantity of the first blockchain node; Based on the first transaction processing quantity, the first blockchain node generates second voting information for the first proposal.

7. The method according to claim 6, characterized in that, The step of verifying the first voting information of the second blockchain node based on the first transaction execution scope and the second transaction execution scope, and obtaining the voting verification result corresponding to the first voting information of the second blockchain node, includes: If the number of transactions within the first transaction execution range is greater than the number of transactions within the second transaction execution range, then candidate execution information corresponding to the second transaction execution range is determined from the transaction execution information corresponding to the first transaction execution range. Perform a hash operation on the candidate execution information to obtain the first block verification hash; If the first block verification hash is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

8. The method according to claim 6, characterized in that, The step of verifying the first voting information of the second blockchain node based on the first transaction execution scope and the second transaction execution scope, and obtaining the voting verification result corresponding to the first voting information of the second blockchain node, includes: If the number of transactions within the execution scope of the first transaction is equal to the number of transactions within the execution scope of the second transaction, then the first block hash in the first voting information of the first blockchain node is compared with the second block hash in the first voting information of the second blockchain node. If the first block hash in the first voting information of the first blockchain node is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

9. The method according to claim 6, characterized in that, The step of verifying the first voting information of the second blockchain node based on the first transaction execution scope and the second transaction execution scope, and obtaining the voting verification result corresponding to the first voting information of the second blockchain node, includes: If the number of transactions within the first transaction execution range is less than the number of transactions within the second transaction execution range, then the difference transaction between the first transaction execution range and the second transaction execution range is executed to obtain the execution information of the difference transaction; The execution information of the differential transaction and the execution information of the transaction corresponding to the execution scope of the first transaction are hashed to obtain the second block verification hash; If the second block verification hash is equal to the second block hash in the first voting information of the second blockchain node, then the voting verification result corresponding to the first voting information of the second blockchain node is determined to be verified as passed.

10. The method according to claim 6, characterized in that, The step of determining the first transaction processing quantity of the first blockchain node based on the first voting information in the voting set includes: If the number of transactions within the second transaction execution range in the voting set is less than or equal to the number of transactions within the first transaction execution range, then the number of transactions within the first transaction execution range is determined as the first transaction processing number of the first blockchain node; If the number of transactions within the second transaction execution range in the voting set is greater than the number of transactions within the first transaction execution range, then the maximum number of transactions within the second transaction execution range in the voting set is determined as the first transaction processing number of the first blockchain node.

11. The method according to claim 6, characterized in that, The step of generating second voting information for the first blockchain node regarding the first proposal based on the first transaction processing quantity includes: Based on the transaction indicated by the first transaction processing quantity, the first block hash in the first voting information of the first blockchain node is updated to obtain the third block hash; Based on the first transaction processing quantity and the third block hash, the first blockchain node generates second voting information for the first proposal.

12. The method according to claim 2, characterized in that, The step of determining the consensus result of the first proposal based on the second voting information of the at least two blockchain nodes includes: In the second voting information of the at least two blockchain nodes, the number of votes in favor of the first proposal is counted; If the number of votes in favor is greater than the voting threshold, then the consensus result of the first proposal is determined to be a successful consensus. If the number of votes in favor is less than or equal to the voting threshold, then the consensus result of the first proposal is determined to be a consensus failure.

13. The method according to any one of claims 1 to 12, characterized in that, The step of obtaining the set of processed transactions of the first blockchain node in the first proposal based on the first transaction processing quantity, and generating a second proposal based on the set of processed transactions, includes: According to the order of transactions in the transaction list of the first proposal, the transactions in the transaction list are added to the processed transaction set of the first blockchain node; the number of transactions in the processed transaction set is equal to the number of transactions processed in the first proposal. The first transaction processing quantity and the transactions in the processed transaction set are encapsulated into the second proposal; the second proposal includes the third block hash in the second voting information of the first blockchain node.

14. A data processing method in a blockchain system, characterized in that, The blockchain system includes at least two blockchain nodes participating in consensus, the at least two blockchain nodes including a first blockchain node, and the method includes: The second proposal is received from the first blockchain node. The second proposal is generated based on the set of processed transactions of the first blockchain node. The set of processed transactions includes the transactions obtained in the first proposal when the consensus result of the first proposal indicates that the consensus has failed, based on the first number of transactions processed by the first blockchain node for the first proposal. The second proposal was processed through consensus.

15. The method according to claim 14, characterized in that, The second proposal includes a third block hash; The consensus processing for the second proposal includes: Obtain the first transaction processing count in the second proposal, and obtain the second transaction processing count of the second blockchain node for the first proposal; Based on the first transaction processing quantity and the second transaction processing quantity, the hash of the third block in the second proposal is verified to obtain the hash verification result; If the hash verification result indicates that the verification is successful, then the approval vote information for the second proposal is generated; If the hash verification result indicates that the verification failed, then the opposing vote information for the second proposal is generated.

16. A data processing device in a blockchain system, characterized in that, The blockchain system includes at least two blockchain nodes participating in consensus, the at least two blockchain nodes including a first blockchain node, and the device includes: The first acquisition module is used to acquire the consensus result of the first proposal; The second acquisition module is used to acquire the first transaction processing count of the first blockchain node for the first proposal if the consensus result of the proposal indicates that the consensus has failed. The proposal generation module is used to obtain the set of processed transactions of the first blockchain node from the first proposal based on the first transaction processing quantity, and generate a second proposal based on the set of processed transactions. The proposal broadcasting module is used to broadcast the second proposal in the blockchain system so that the at least two blockchain nodes in the blockchain system can perform consensus processing on the second proposal.

17. A data processing device in a blockchain system, characterized in that, The blockchain system includes at least two blockchain nodes participating in consensus, the at least two blockchain nodes including a first blockchain node, and the device includes: The proposal receiving module is used to receive a second proposal broadcast by the first blockchain node; the second proposal is generated based on the set of processed transactions of the first blockchain node, the set of processed transactions including the transactions obtained in the first proposal when the consensus result of the first proposal indicates that the consensus has failed, based on the first number of transactions processed by the first blockchain node for the first proposal; The consensus processing module is used to process the second proposal.

18. A computer device, characterized in that, Including memory and processor; The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to invoke the computer programs to cause the computer device to perform the method according to any one of claims 1 to 13, or to perform the method according to any one of claims 14 to 15.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1 to 13, or to perform the method of any one of claims 14 to 15.

20. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method of any one of claims 1 to 13, or implements the method of any one of claims 14 to 15.

Images