Consensus processing method based on block chain network and related equipment

Abstract

The invention discloses a block chain network-based consensus processing method and related equipment, and the method comprises the steps: recognizing a specific transaction in N transactions to be consensus, constructing target additional data through employing a transaction identifier of the recognized specific transaction, generating a target proposal through employing the target additional data and the N transactions, each node in the block chain network constructs a first voting result about the target proposal, and any first voting result comprises a proposal ticket generated by voting the target proposal; the voting result constructed by the specified node further comprises a transaction ticket which is generated based on the target additional data and is used for representing the specific transaction recognized by the specified node; and collecting a first voting result constructed by each node, and determining a consensus result of the N transactions based on the collected first voting result. It can be seen that the whole consensus processing flow does not need participation of the service party, so that the processing complexity of the service party is reduced, and the availability of the block chain network is improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to the field of blockchain technology, and in particular to a consensus processing method and related equipment based on a blockchain network. Background Technology

[0002] With the development of blockchain technology, more and more business systems are beginning to use blockchain networks. A blockchain network, also known as a blockchain system, is a distributed system composed of multiple different consensus nodes (simply called nodes). Each node can execute all transactions, and the process of voting on the transaction itself and the execution result to reach a consensus is called consensus. In practical business systems, for certain sensitive transactions, business parties often want the transaction to be approved by designated nodes before it can pass consensus.

[0003] Currently, to address such business needs, the business party typically needs to first send the specific transaction to a designated node, where the node signs the transaction to indicate its approval. The business party then aggregates the signatures from the designated node to obtain the signed transaction, which is then sent to the blockchain network. The nodes in the blockchain network verify the transaction's signature before voting to achieve consensus. It is evident that the existing consensus processing flow for specific transactions is quite complex and requires the business party to aggregate signatures, increasing the complexity of the business process and resulting in low availability of the blockchain network. Summary of the Invention

[0004] This application provides a consensus processing method and related equipment based on a blockchain network, which can simplify the consensus processing process for specific transactions, so that the entire consensus processing process does not require the participation of the business party, thereby reducing the complexity of the business party's processing and improving the availability of the blockchain network.

[0005] On one hand, embodiments of this application provide a consensus processing method based on a blockchain network, the method comprising:

[0006] Obtain N transactions awaiting consensus and identify a specific transaction among the N transactions; N is a positive integer, and the specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before reaching consensus;

[0007] Target supplementary data is constructed using the transaction identifiers of the identified specific transactions, and a target proposal is generated using the target supplementary data and the N transactions;

[0008] The target proposal is broadcast in the blockchain network, causing each node in the blockchain network to construct a first voting result regarding the target proposal; wherein any first voting result includes: a proposal vote generated by voting on the target proposal, and the voting result constructed by the designated node also includes: a transaction vote generated based on the target additional data, the transaction vote indicating that the designated node agrees with the identified specific transaction;

[0009] Collect the first voting results constructed by each node, and determine the consensus result of the N transactions based on the collected first voting results.

[0010] On the other hand, embodiments of this application provide a consensus processing device based on a blockchain network, the device comprising:

[0011] The processing unit is used to acquire N transactions to be reached in consensus and identify a specific transaction among the N transactions; N is a positive integer, and the specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before reaching consensus;

[0012] The processing unit is further configured to construct target additional data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target additional data and the N transactions;

[0013] A consensus unit is used to broadcast the target proposal in a blockchain network, enabling each node in the blockchain network to construct a first voting result regarding the target proposal; wherein any first voting result includes: a proposal vote generated by voting on the target proposal, and the voting result constructed by the designated node further includes: a transaction vote generated based on the target additional data, the transaction vote indicating that the designated node agrees with the identified specific transaction;

[0014] The consensus unit is also used to collect the first voting results constructed by each node, and to determine the consensus result of the N transactions based on the collected first voting results.

[0015] In one implementation, when the processing unit is used to identify a specific transaction among the N transactions, it may specifically be used to:

[0016] Obtain configuration information, which includes: at least one trading group configured for a specific exchange and a trading identification strategy under each trading group; any trading identification strategy is used to indicate: the attribute information that a specific transaction under the corresponding trading group should possess;

[0017] For the nth transaction among the N transactions, traverse each transaction group in the configuration information, and take the transaction identification strategy under the currently traversed ith transaction group as the ith transaction identification strategy; where n∈[1,N], and i is a positive integer less than or equal to the number of transaction groups;

[0018] If the nth transaction possesses the attribute information indicated by the i-th transaction identification strategy, then the nth transaction is identified as a specific transaction under the i-th transaction group, and the process continues to traverse each transaction group in the configuration information.

[0019] If the nth transaction does not possess the attribute information indicated by the ith transaction identification strategy, then the process continues to traverse each transaction group in the configuration information.

[0020] In another implementation, when the processing unit constructs target additional data using the transaction identifier of the identified specific transaction, it may specifically be used to:

[0021] Obtain the transaction group for each specific transaction identified;

[0022] Based on the transaction group of each specific transaction, the transaction identifiers of each specific transaction are grouped to obtain at least one identifier group; wherein, an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group, and the transaction groups in different identifier groups are different;

[0023] Using the at least one identifier group, construct the target additional data.

[0024] In another implementation, when the processing unit generates the target proposal using the target additional data and the N transactions, it may specifically be used to:

[0025] An initial proposal is generated using the N transactions, and the initial proposal includes an additional data structure;

[0026] The target additional data is populated into the additional data structure in the initial proposal to obtain the target proposal.

[0027] In another implementation, the consensus unit, when constructing the first voting result regarding the target proposal, may specifically be used to:

[0028] Execute N transactions in the target proposal to obtain transaction execution results; and vote on the target proposal based on the transaction execution results to generate proposal votes, which are used to instruct the corresponding nodes to support or oppose the target proposal.

[0029] The transaction indicated by the transaction identifier in the target additional data of the target proposal is identified as a specific transaction; and the voting qualification of the k-th node to vote in favor of the identified specific transaction is detected.

[0030] If the kth node is detected to have the voting qualification, a transaction ticket is generated based on the target additional data, and the generated proposal ticket and transaction ticket are used to construct the first voting result; if the kth node is detected to not have the voting qualification, the generated proposal ticket is used to construct the first voting result.

[0031] Where k is a positive integer, and is less than or equal to the number of nodes in the blockchain network.

[0032] In another embodiment, the target additional data includes the at least one identifier group, wherein an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group;

[0033] Accordingly, when the consensus unit is used to detect the voting eligibility of the k-th node to vote in favor of the identified specific transaction, it can be specifically used for:

[0034] Obtain configuration information, which includes a group field and at least one node field; the group field stores at least one transaction group, one transaction group corresponds to one node field, and any node field stores a list of nodes configured for the corresponding transaction group, the list of nodes including at least one node identifier;

[0035] Iterate through each identifier group in the target additional data, and obtain the node list in the node field corresponding to the transaction group in the currently traversed identifier group from the configuration information;

[0036] If the obtained list of nodes includes the node identifier of the kth node, then the kth node is determined to have the voting qualification to vote in favor of the identified specific transaction.

[0037] If the obtained list of nodes does not include the node identifier of the kth node, the traversal continues until all the identifier groups have been traversed, and it is determined that the kth node does not have the qualification to vote.

[0038] In another implementation, the target proposal further includes: a transaction topology graph and a first block hash; the transaction topology graph is used to indicate the transaction execution order among the N transactions, and the first block hash is obtained by hashing the execution results of the N transactions after they are executed; wherein the k-th node executes the N transactions according to the transaction execution order indicated by the transaction topology graph;

[0039] Accordingly, when the consensus unit is used to vote on the target proposal based on the transaction execution result to generate proposal votes, it can be specifically used for:

[0040] The transaction execution result is hashed to obtain the second block hash;

[0041] Perform a consistency check between the hash of the second block and the hash of the first block in the target proposal;

[0042] If the second block hash and the first block hash pass the consistency check, then vote in favor of the target proposal as a proposal vote;

[0043] If the second block hash and the first block hash fail the consistency check, then a vote against the target proposal is cast as a proposal vote.

[0044] In another implementation, if the second block hash and the first block hash pass the consistency check, the consensus unit can also be used for:

[0045] Identify a specific transaction among the N transactions, and construct reference supplementary data using the transaction identifier of the identified specific transaction;

[0046] Based on the aforementioned reference supplementary data, the correctness of the target supplementary data in the target proposal is verified.

[0047] If the correctness of the target supplementary data passes the verification, the step of casting a support vote for the target proposal as a proposal vote is triggered; if the correctness of the target supplementary data fails the verification, a negative vote is cast for the target proposal as a proposal vote.

[0048] In another implementation, when the consensus unit is used to generate a transaction ticket based on the target additional data, it may specifically be used to:

[0049] Perform a hash operation on the transaction identifier in the target additional data to obtain the transaction hash value;

[0050] The transaction hash value is used as the transaction ticket.

[0051] In another implementation, when the consensus unit is used to determine the consensus result of the N transactions based on the collected first voting results, it can specifically be used for:

[0052] In the first voting results collected, the number of proposal votes used to support the target proposal is counted to obtain the first vote count; and in the first voting results collected, the number of first voting results containing the transaction vote is counted to obtain the second vote count;

[0053] Based on the first number of votes and the second number of votes, a second voting result is constructed. The constructed second voting result is used to indicate whether to support or oppose the N transactions through consensus.

[0054] The constructed second voting result is broadcast in the blockchain network, and the second voting result broadcast by other nodes in the blockchain network is received.

[0055] Based on the collected second voting results, the consensus result of the N transactions is determined; wherein, the collected second voting results include: the constructed second voting results and the received voting results.

[0056] In another implementation, when the consensus unit is used to construct a second voting result based on the first number of votes and the second number of votes, it can specifically be used to:

[0057] A first threshold number is determined, which refers to the minimum number of proposal votes required to support the target proposal before the target proposal is determined to pass consensus.

[0058] When the first number of votes is less than the first threshold number, a second voting result is constructed to oppose the consensus of the N transactions.

[0059] When the first number of votes is greater than or equal to the first threshold number, a second threshold number is determined. The second threshold number refers to the minimum number of designated nodes that need to endorse the identified specific transaction.

[0060] If the second number of votes is greater than or equal to the second threshold number, a second voting result is constructed to support the consensus of the N transactions; if the second number of votes is less than the second threshold number, a second voting result is constructed to oppose the consensus of the N transactions.

[0061] In another implementation, if the second number of votes is less than the second threshold number, the consensus unit can also be used for:

[0062] Start the timer used for timing;

[0063] When the duration of the timer exceeds the duration threshold, the number of first voting results containing the transaction votes is counted again from the collected first voting results to obtain the third voting count;

[0064] If the number of third votes is greater than or equal to the number of the second threshold, a second voting result is constructed to support the consensus of the N transactions; if the number of third votes is less than the number of the second threshold, the step of constructing a second voting result to oppose the consensus of the N transactions is triggered.

[0065] In another implementation, after determining the consensus result of the N transactions, the consensus unit can also be used for:

[0066] If the consensus result indicates that the N transactions have failed to pass the consensus, then the N transactions are pruned to obtain the remaining transactions, which do not include the identified specific transactions;

[0067] A new proposal is constructed using the remaining transactions, and consensus processing is performed on the new proposal.

[0068] In another aspect, embodiments of this application provide a computer device, the computer device including an input interface and an output interface, the computer device further including:

[0069] Processor and computer storage media;

[0070] The processor is adapted to implement one or more instructions, and the computer storage medium stores one or more instructions, which are adapted to be loaded and executed by the processor to perform the aforementioned consensus processing method based on a blockchain network.

[0071] In another aspect, embodiments of this application provide a computer storage medium storing one or more instructions, which are adapted to be loaded by a processor and executed by the aforementioned consensus processing method based on a blockchain network.

[0072] In another aspect, embodiments of this application provide a computer program product comprising one or more instructions; when one or more instructions in the computer program product are executed by a processor, they implement the aforementioned consensus processing method based on a blockchain network.

[0073] This embodiment of the application allows a node in the blockchain network to obtain N transactions to be reached through consensus, automatically identify a specific transaction among the N transactions, construct target supplementary data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target supplementary data and the N transactions. The target proposal is then broadcast in the blockchain network, allowing all nodes in the blockchain network to vote on the target proposal. During the voting process, designated nodes can also generate transaction tickets based on the target supplementary data to indicate their agreement with the identified specific transaction. This enables each node to construct a first voting result regarding the target proposal. Furthermore, by collecting the first voting results constructed by each node, a consensus result for the N transactions is determined based on the collected first voting results. Therefore, this embodiment of the application allows nodes in the blockchain network to complete the identification and voting of specific transactions, simplifying the consensus processing flow for specific transactions. This eliminates the need for business parties to participate in the entire consensus processing flow, thereby reducing the complexity of business parties' processing and improving the availability of the blockchain network. Attached Figure Description

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

[0075] Figure 1 This is a schematic diagram illustrating the working principle of a processing model for a specific transaction provided in an embodiment of this application;

[0076] Figure 2 This is a flowchart illustrating a consensus processing method based on a blockchain network provided in an embodiment of this application;

[0077] Figure 3a This is a schematic diagram illustrating the construction of target supplementary data provided in an embodiment of this application;

[0078] Figure 3b This is a schematic diagram illustrating how target supplementary data is populated into an initial proposal, as provided in an embodiment of this application.

[0079] Figure 4 This is a flowchart illustrating a consensus processing method based on a blockchain network, provided in another embodiment of this application.

[0080] Figure 5a This is a schematic diagram illustrating the construction of a first voting result provided in an embodiment of this application;

[0081] Figure 5b This is a schematic diagram illustrating the trimming of N transactions according to an embodiment of this application;

[0082] Figure 6a This is a schematic diagram of the consensus process corresponding to a consensus algorithm provided in an embodiment of this application;

[0083] Figure 6b This is a schematic diagram of the consensus process corresponding to another consensus algorithm provided in the embodiments of this application;

[0084] Figure 6c This is a schematic diagram of the consensus process of a modified consensus algorithm provided in an embodiment of this application;

[0085] Figure 6d This is a schematic diagram of the processing logic for generating a first voting result from a node, provided in an embodiment of this application;

[0086] Figure 6e This is a schematic diagram of a two-round voting process for a slave node provided in an embodiment of this application;

[0087] Figure 7 This is a schematic diagram of the structure of a consensus processing device based on a blockchain network provided in an embodiment of this application;

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

[0089] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0090] To address the issue that business parties (clients) need to aggregate signatures, and that consensus nodes (referred to as nodes) in the blockchain network need to verify the signatures of transactions during the consensus process, which leads to complex actual processing of specific transactions, this application proposes a consensus processing method based on a blockchain network. This method can be applied to the actual development process of blockchain underlying software, as well as to the external promotion of blockchain technology. This application does not limit its application scenarios.

[0091] Specifically, the consensus processing method based on a blockchain network proposed in this application can be executed during the consensus phase. Its core requirement is to configure a processing model (i.e., processing logic) for a specific transaction within the blockchain network. See also... Figure 1 As shown, the working principle of this processing model is roughly as follows:

[0092] Step 1: The business party (client) sends a specific transaction to any node in the blockchain network (e.g., ...). Figure 1After node 1 in the blockchain, the corresponding node (e.g., node 1) stores the specific transaction in its own transaction pool (storage space used to store transactions) and broadcasts the specific transaction in the blockchain network, so that other nodes in the blockchain network (e.g., node 1) can also broadcast the transaction. Figure 1 Nodes 2, 3, and 4 in the system each store specific transactions into their respective transaction pools.

[0093] Step 2, Master Node (the consensus node used to generate proposals, for example...) Figure 1 Node 1) retrieves a specific transaction from the transaction pool, generates a proposal using that specific transaction, and broadcasts the proposal throughout the blockchain network, enabling all nodes in the blockchain network (such as...) to participate. Figure 1 The nodes 1, 2, 3 and 4 in the process reach a consensus on the proposal (i.e., reach a consensus on a specific transaction).

[0094] Step 3: Specify the node (i.e., the node specified by the business party, for example...) Figure 1 Node 2) in the consensus process can vote on proposals to generate proposal votes and vote on specific transactions to generate transaction votes, thereby constructing a voting result containing proposal votes and transaction votes and broadcasting the voting result; nodes other than designated nodes (such as...) Figure 1 Nodes 1, 3, and 4 in the system vote on the proposal to generate proposal votes, thereby constructing a voting result containing the proposal votes and broadcasting the voting result.

[0095] Step 4, each node (e.g.) Figure 1 Nodes 1, 2, 3, and 4 can collect the voting results and determine whether a specific transaction has passed consensus by verifying the proposal votes and transaction votes in the collected voting results.

[0096] Based on the descriptions of steps 1-4 above, the consensus processing method based on a blockchain network proposed in this application embodiment can support the business party (client) to send only specific transactions to the blockchain network, and all other operations can be completed by the nodes within the consensus process without the business party performing other operations. This simplifies the consensus processing flow for specific transactions, so that the entire consensus processing flow does not require the participation of the business party (client), thereby reducing the complexity of the business party (client) processing and improving the availability of the blockchain network.

[0097] Based on the above description of the consensus processing method based on blockchain networks proposed in this application, it is worth emphasizing that:

[0098] ① The term "transaction" mentioned in the embodiments of this application is a term in the field of blockchain technology. It can be the transfer of resources, a transaction, a message, or data sent by one object to another. Executing a transaction can be understood as calling and executing a smart contract. A smart contract, or simply a contract, is a piece of code statements with processing logic. During execution, a contract can perform read and write operations. Therefore, after executing a transaction (i.e., executing a contract), a transaction read-write set can be generated. This transaction read-write set can include the contract names of each smart contract called during the execution of the transaction, as well as the operation results of each operation generated by each called smart contract during execution, and so on.

[0099] ② The nodes mentioned in the embodiments of this application are essentially computer devices, which can be terminals or servers. Terminals can be smartphones, computers (such as tablets, laptops, desktop computers, etc.), smart wearable devices (such as smartwatches, smart glasses), smart voice interaction devices, smart home appliances (such as smart TVs), vehicle terminals, or aircraft, etc.; servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide 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, etc.

[0100] ③ In this application embodiment, data related to user information (such as specific transactions sent by the business party) is involved. When any method embodiment proposed in this application embodiment is applied to a specific product or technology, this related data is collected with the user's permission or consent, and the collection, use and processing of the related data comply with the relevant laws, regulations and standards of the relevant region.

[0101] Based on the above description, the following is combined with Figure 2 The flowchart shown illustrates the specific implementation process of the consensus processing method based on a blockchain network proposed in this application embodiment; in this application embodiment, the method is illustrated using the master node (i.e., the consensus node used to generate proposals) as an example. Please refer to... Figure 2 As shown, the method can be roughly divided into the following steps S201-S204:

[0102] S201: Obtain N transactions awaiting consensus and identify a specific transaction among the N transactions.

[0103] In a specific implementation, the master node can be configured with a transaction pool, which can store one or more transactions awaiting consensus. Based on this, when the master node obtains N transactions awaiting consensus in step S201, it can directly retrieve N transactions from its local transaction pool as the N transactions awaiting consensus, where N is a positive integer. Optionally, in other implementations, the master node can also receive N transactions uploaded by the business party in real time, thereby using the received N transactions as the N transactions awaiting consensus. This application embodiment does not limit the specific implementation method for obtaining the N transactions awaiting consensus.

[0104] For N transactions awaiting consensus, the master node can automatically identify a specific transaction among the N transactions. A specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before reaching consensus. This designated node refers to a node specified by the business party. For example, if the business party specifies that transaction 'a' needs to be recognized by node 1 in the blockchain network before reaching consensus, then node 1 is the designated node, and transaction 'a' is the specific transaction. It is understood that the designated node and the master node may be the same node or two different nodes; this embodiment does not limit this.

[0105] Research indicates that specific transactions may include, but are not limited to, the following:

[0106] 1) Transaction of specific contract (or method): When this type of transaction is executed, it will directly call a specific contract (i.e. a specific smart contract, such as a smart contract specified by the business party). Since the transaction information of any transaction can contain the contract name of the smart contract that the corresponding transaction needs to call directly when it is executed, this type of transaction can be determined as a specific transaction by whether the contract name in its transaction information is the contract name of a specific contract without execution.

[0107] 2) Transactions sent by a specific organization (such as a user or enterprise): Since the transaction information of any transaction may contain the name of the sender of the corresponding transaction (hereinafter referred to as the organization name), such transactions can be judged as specific transactions by whether the organization name in the transaction information is the organization name of a specific organization without execution.

[0108] 3) Transactions that require calling specific contracts during execution: This type of transaction is the most common. When it is executed within a smart contract, it will call the processing logic of other smart contracts across contracts. The smart contract being called can be a relatively basic but very important smart contract. For this type of transaction, it is necessary to execute it to obtain the transaction read-write set before it can be determined whether the corresponding transaction is a specific transaction by checking whether the contract name in the transaction read-write set is the contract name of a specific contract.

[0109] Based on this, one implementation method for the master node to identify a specific transaction among N transactions can be: obtaining specific transaction identification information, which may include at least one of the following: the contract name of at least one specific contract and the organization name of at least one specific organization; traversing N transactions, taking the currently traversed transaction as the current transaction, obtaining the transaction information of the current transaction, and executing the current transaction to obtain the transaction read / write set of the current transaction. Matching the transaction information of the current transaction with the specific transaction identification information, and matching the transaction read / write set of the current transaction with the specific transaction identification information, to obtain a matching result. If the matching result indicates at least one of the following: ① the contract name in the transaction information of the current transaction is present in the specific transaction identification information; ② the organization name in the transaction information of the current transaction is present in the specific transaction identification information; ③ the contract name in the transaction read / write set of the current transaction is present in the specific transaction identification information; then, the current transaction can be identified as a specific transaction; otherwise, the current transaction can be identified as a non-specific transaction.

[0110] Alternatively, considering that different types of specific transactions possess different attribute information, such as the attribute information of transactions of a specific contract (or method) class including the contract name of the smart contract directly called during the execution of the transaction, the attribute information of transactions sent by a specific object (such as a user or organization) including the organization name, and the attribute information of transactions that need to call a specific contract during execution including the contract name in the transaction read / write set generated by the execution of the transaction; and that different specific transactions need to be recognized by different designated nodes, such as transactions of a specific contract (or method) class need to be recognized by node 1, and transactions sent by a specific object (such as a user or organization) and transactions that need to call a specific contract during execution both need to be recognized by node 2. Based on this, the embodiments of this application can support target objects (such as business parties or blockchain network operation and maintenance personnel) to configure at least one transaction group for specific transactions based on actual needs, and configure a transaction identification strategy and node list under each transaction group, so as to realize the group identification and group consensus (or hierarchical consensus) of specific transactions, thereby improving the diversity and flexibility of consensus processing. Among them, any transaction identification strategy is used to indicate: the attribute information that a specific transaction under the corresponding transaction group should have; any node list includes at least one node identifier, which is used to identify the node used to recognize a specific transaction under the corresponding transaction group.

[0111] Based on this, another implementation method for the master node to identify a specific transaction among N transactions can be: obtaining configuration information, which can be pre-configured by the target object, and the configuration information can include: at least one transaction group configured for a specific transaction and a transaction identification strategy under each transaction group. For the nth transaction among N transactions, traverse each transaction group in the configuration information, and take the transaction identification strategy under the currently traversed i-th transaction group as the i-th transaction identification strategy; where n∈[1,N], i is a positive integer less than or equal to the number of transaction groups. Detect whether the nth transaction has the attribute information indicated by the i-th transaction identification strategy; if the nth transaction has the attribute information indicated by the i-th transaction identification strategy, then the nth transaction is identified as a specific transaction under the i-th transaction group, and the traversal of each transaction group in the configuration information continues; if the nth transaction does not have the attribute information indicated by the i-th transaction identification strategy, then the traversal of each transaction group in the configuration information continues. Understandably, if the nth transaction does not possess the attribute information indicated by all transaction identification strategies, then the nth transaction can be identified as a non-specific transaction.

[0112] Furthermore, the configuration information mentioned above can be represented by text. Alternatively, to allow for flexible modification of the configuration information and thus improve the scalability of the entire method, the configuration information mentioned above can also be represented by fields. In this case, the configuration information mentioned above may include a group field (MutliLayerConsensus), which stores at least one transaction group, meaning that the value of the group field includes at least one transaction group. The i-th transaction identification strategy under the i-th transaction group may include: a type field and M information fields, where M is a positive integer. The type field indicates the M attribute types and the logical relationships between them. Each attribute type corresponds to one information field, and the value of any information field includes: the attribute information that a specific transaction under the i-th transaction group should possess under the corresponding attribute type. Furthermore, the M attribute types may include at least one of the following: a first contract name type, a second contract name type, and an organization name type. Among them: ① The attribute information under the first contract name type includes the first contract name, which refers to the contract name in the transaction read / write set generated by executing the transaction; ② The attribute information under the second contract name type includes the second contract name, which refers to the contract name of the smart contract directly called when the transaction is executed; ③ The attribute information under the organization name type includes the organization name, which refers to the name of the sender of the transaction.

[0113] It should be noted that the logical operation relationship between the M attribute types mentioned above can be either an AND relationship or an OR relationship, without limitation. When the logical operation relationship between the M attribute types is an AND relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under each of the M attribute types; when the logical operation relationship between the M attribute types is an OR relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under any one of the M attribute types. For example, suppose there are M attribute types, including: first contract name type, second contract name type, and organization name type. If the logical operation relationship between the M attribute types is an AND relationship, then the attribute information indicated by the i-th transaction identification strategy includes: first contract name, second contract name, and organization name. In this case, the n-th transaction must simultaneously possess the first contract name, second contract name, and organization name indicated by the i-th transaction identification strategy to be identified as a specific transaction. If the logical operation relationship between the M attribute types is an OR relationship, then the attribute information indicated by the i-th transaction identification strategy includes: first contract name, second contract name, or organization name. In this case, the n-th transaction only needs to possess the first contract name, second contract name, or organization name indicated by the i-th transaction identification strategy to be identified as a specific transaction.

[0114] Furthermore, when the attribute information indicated by the i-th transaction identification strategy includes the first contract name, since the first contract name refers to the contract name in the transaction read / write set generated by executing the transaction, the master node can detect whether the n-th transaction possesses the attribute information indicated by the i-th transaction identification strategy by: obtaining the transaction read / write set of the n-th transaction and detecting whether the transaction read / write set of the n-th transaction contains the first contract name. When the attribute information indicated by the i-th transaction identification strategy includes the second contract name, since the second contract name refers to the contract name of the smart contract directly called during transaction execution, and the transaction information can contain the contract name of the smart contract directly called by the transaction, the master node can detect whether the n-th transaction possesses the attribute information indicated by the i-th transaction identification strategy by: obtaining the transaction information of the n-th transaction and detecting whether the transaction information of the n-th transaction contains the second contract name. Similarly, when the attribute information indicated by the i-th transaction identification strategy includes the organization name, the master node can detect whether the n-th transaction has the attribute information indicated by the i-th transaction identification strategy by: obtaining the transaction information of the n-th transaction and detecting whether the transaction information of the n-th transaction includes the organization name.

[0115] Based on the above description, in order to improve the overall scalability, this application embodiment provides the following configurations for the blockchain network for business users to adjust:

[0116] (1) key (field): MutliLayerConsensus (group field) / / A fixed field that can be used for hierarchical consensus;

[0117] value (field value): eX (transaction group), ORG1 (transaction group) / / Any two transaction groups are separated by a comma. Here, eX and ORG1 are used as examples to represent transaction groups. In other embodiments, transaction groups can also be represented as Key1, Key2, Key3, etc.

[0118] (2) key (field): eX-Types (type field in the transaction identification strategy under transaction group eX) / / This is only an example of eX-Types. It does not exhaustively list all the type fields in the transaction identification strategy under the transaction group. It can be understood that eX is a variable field. For example, eX can be changed to ORG1 to represent ORG1-Types (type field in the transaction identification strategy under transaction group ORG1).

[0119] value (field value): "0||1" / / 0 represents the first contract name type, 1 represents the organization name type, and || represents an OR relationship; this example only uses "0||1" and does not limit the value of eX-Types. For example, its value can also be "1||2", where 2 represents the second contract name type. In addition to using || for relationship mapping between multiple attribute types, && (AND relationship) can also be used for relationship mapping. It should be noted that 0 and 1 can also be forcibly constrained to correspond to the two fields eX-Keys-0 and eX-Keys-1.

[0120] (3) key (field): eX-Keys-0 / / In the case of attribute type 0, the field where the keyword is located is determined (i.e. the information field corresponding to attribute type 0). It can be understood that eX here is a variable field, and its value is a string representing the transaction group, which depends on the eX-Type field. For example, eX can be changed to ORG1 to represent ORG1-Keys-0.

[0121] value(field value): "eX" / / Attribute information in the information field corresponding to attribute type 0 (which corresponds to the first contract name mentioned above).

[0122] (4) key(field): eX-Keys-1 / / In the case of attribute type 1, the field where the keyword is located (i.e. the information field corresponding to attribute type 1). It can be understood that eX is a variable field, and its value is a string representing the transaction group, which depends on the eX-Type field. For example, eX can be changed to ORG1 to represent ORG1-Keys-1.

[0123] value (field value): "www.org.cn" / / Attribute information in the information field corresponding to attribute type 1 (which corresponds to the organization name mentioned above).

[0124] (5) key (field): eX-Nodes / / List of nodes to be determined. It is understood that eX is a variable field, and its value is a string representing the transaction group, which depends on the eX-Type field. For example, eX can be changed to ORG1 to represent ORG1-Nodes.

[0125] value (field value): "C4, 5Q" / / C4 and Q5 represent strings that can be separated by commas. The content is a simplified node identifier. The last two characters of the node identifier can be used directly, as long as they are unique and not repeated, thus saving storage space occupied by the node identifier. Understandably, if there is a repetition, three or more characters should be used. C4 and Q5 can form a list of nodes, but this is just an example of two node identifiers, C4 and Q5. In actual applications, there can be more node identifiers or only one node identifier.

[0126] Based on the above, the embodiments of this application support the logical operations of "AND" and "OR" in terms of scalability, mainly including two parts:

[0127] ① Multiple judgment methods are supported. "0||1" means that the contract namespace and organization of the transaction read / write set can be used. The corresponding value will be configured in ${Key}-Keys-0 and ${Key}-Keys-1. "0&&1" means that both the contract namespace and organization of the transaction read / write set must be satisfied. Here, ${Key} is a variable and its value can be the transaction group mentioned above, such as eX or ORG1.

[0128] ② Any information field ${Key}-Keys-${index} can also internally support "AND" and "OR" relationships; where ${index} is a variable whose value can take the attribute type mentioned above, such as attribute type 0, 1, 2, etc.; for example, ${Key}-Keys-0: "save1||save2" means that when using the contract namespace, both the contract names save1 and save2 are acceptable.

[0129] S202, construct target supplementary data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target supplementary data and N transactions.

[0130] In a specific implementation, the master node constructs target supplementary data using the transaction identifiers of identified specific transactions in a sequential manner to obtain the target supplementary data. Alternatively, if the master node identifies specific transactions using the aforementioned configuration information, the specific implementation of constructing target supplementary data using the transaction identifiers of identified specific transactions can be as follows: The master node obtains the transaction groups of each identified specific transaction, and based on each specific transaction group, groups the transaction identifiers of each specific transaction to obtain at least one identifier group; wherein an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group, and the transaction groups in different identifier groups are different. Furthermore, at least one identifier group can be used to construct the target supplementary data, such as by sequentially arranging at least one identifier group to obtain the target supplementary data, so that subsequent group consensus can be achieved based on the target supplementary data.

[0131] For example, see Figure 3a As shown: Suppose the transaction identifiers of the identified specific transactions are TxID1, TxID2, TxID3, and TxID5, and the transaction groups of the specific transactions are Key1, Key2, Key1, and Key2, then two identifier groups can be obtained through grouping. The first identifier group includes the transaction group Key1 and the two transaction identifiers TxID1 and TxID3, and the second identifier group includes the transaction group Key2 and the two transaction identifiers TxID2 and TxID5. These two identifier groups can then be arranged in order to obtain the target additional data.

[0132] Furthermore, considering that the proposal contains an AdditionalData structure (an additional data structure not used to calculate the BlockHash), see [link to relevant documentation]. Figure 3b As shown: When the master node generates a target proposal using target supplementary data and N transactions, it can generate an initial proposal using the N transactions. This initial proposal includes an additional data structure (AdditionalData structure). The target supplementary data can then be populated (encapsulated) into the AdditionalData structure of the initial proposal to obtain the target proposal. This allows subsequent nodes to extract the target supplementary data from the AdditionalData structure within the target proposal, enabling verification and computation based on the target supplementary data. This allows for the embedding of target supplementary data without altering the proposal's data structure. It is understood that this is merely an illustrative example of one specific implementation for generating a target proposal and is not exhaustive. For example, in other embodiments, the master node can also package the target supplementary data and N transactions to obtain new data, and then use this new data to generate the target proposal, and so on.

[0133] S203 broadcasts the target proposal in the blockchain network, enabling the nodes in the blockchain network to construct the first vote on the target proposal.

[0134] The first voting result includes: a proposal vote generated by voting on the target proposal; and the voting result constructed by the designated node also includes: a transaction vote generated based on the target additional data, which indicates that the designated node agrees with the identified specific transaction. It is understood that the nodes in the blockchain network include master nodes, meaning that master nodes can also construct the first voting result regarding the target proposal.

[0135] When constructing the first voting result for a target proposal, any node can check whether it is a designated node. If it is a designated node, it can vote on the target proposal to generate a proposal vote and generate a transaction vote based on the target additional data to indicate its agreement with the identified specific transaction. The generated proposal vote and transaction vote are then used to generate the first voting result for the target proposal. If it is not a designated node, it can only vote on the target proposal to generate a proposal vote. The generated proposal vote is then used to generate the first voting result for the target proposal.

[0136] S204: Collect the first voting results constructed by each node, and determine the consensus result of N transactions based on the collected first voting results.

[0137] In its implementation, after any node in the blockchain network constructs an initial vote on a target proposal, it can broadcast this initial vote across the network, making it available to other nodes. Based on this, the master node can collect the initial votes constructed by each node in the blockchain network and determine the consensus result of N transactions based on the collected initial votes.

[0138] One implementation method for the master node to determine the consensus result of N transactions based on the collected first voting results can be as follows: First, count the number of proposal votes used to support the target proposal from the collected first voting results to obtain the first vote count; second, count the number of first votes containing transaction votes from the collected first voting results to obtain the second vote count. If the first vote count is greater than a first threshold count, and the second vote count is greater than a second threshold count, then N transactions can be determined to have passed consensus, thus generating a consensus result of N transactions; otherwise, N transactions can be determined to have failed to pass consensus, thus generating a consensus result of N transactions. The first threshold count refers to the minimum number of proposal votes required to support the target proposal before it is determined to have passed consensus; for example, if at least 5 proposal votes are required to support the target proposal before it can pass consensus, then the first threshold count can be set to 5. Similarly, the second threshold count refers to the minimum number of designated nodes that must endorse a specific identified transaction; for example, if at least 2 designated nodes must endorse a specific identified transaction, then the second threshold count can be set to 2.

[0139] Alternatively, another implementation method for the master node to determine the consensus result of N transactions based on the collected first voting results can be: Firstly, count the number of proposal votes supporting the target proposal from the collected first voting results to obtain the first vote count; and secondly, count the number of first votes containing transaction votes from the collected first voting results to obtain the second vote count. Based on the first and second vote counts, a second vote count is constructed, which indicates whether to support or oppose the N transactions to pass consensus. The constructed second vote count is broadcast in the blockchain network, and second vote counts broadcast by other nodes in the blockchain network are received. Based on the collected second vote counts, the consensus result of the N transactions is determined. The collected second vote counts include both the constructed second vote count and the received vote counts. It is evident that this method can achieve consensus on N transactions through multiple rounds of voting, thus improving the accuracy of the consensus result.

[0140] This embodiment of the application allows a node in the blockchain network to obtain N transactions to be reached through consensus, automatically identify a specific transaction among the N transactions, construct target supplementary data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target supplementary data and the N transactions. The target proposal is then broadcast in the blockchain network, allowing all nodes in the blockchain network to vote on the target proposal. During the voting process, designated nodes can also generate transaction tickets based on the target supplementary data to indicate their agreement with the identified specific transaction. This enables each node to construct a first voting result regarding the target proposal. Furthermore, by collecting the first voting results constructed by each node, a consensus result for the N transactions is determined based on the collected first voting results. Therefore, this embodiment of the application allows nodes in the blockchain network to complete the identification and voting of specific transactions, simplifying the consensus processing flow for specific transactions. This eliminates the need for business parties to participate in the entire consensus processing flow, thereby reducing the complexity of business parties' processing and improving the availability of the blockchain network.

[0141] Based on the above Figure 2 The method embodiments shown in this application further propose a more specific consensus processing method based on a blockchain network; in this application embodiment, the execution of the method by the master node is still used as an example for illustration. Please refer to... Figure 4 As shown, the method can be roughly divided into the following steps S401-S408:

[0142] S401: Obtain N transactions awaiting consensus and identify a specific transaction among the N transactions.

[0143] S402, construct target supplementary data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target supplementary data and N transactions.

[0144] In its implementation, the master node can generate an initial proposal using N transactions. This initial proposal includes an additional data structure. The target additional data is then populated into the additional data structure of the initial proposal to obtain the target proposal. Specifically, generating the initial proposal using N transactions can be achieved by: executing N transactions to obtain the execution result of each transaction and a transaction topology graph, which indicates the execution order of the N transactions; performing a hash operation on the execution results of the N transactions to obtain the first block hash; and then using the first block hash, the transaction topology graph, and the information from the N transactions to construct the initial proposal. It is understood that the target proposal is obtained by populating the target additional data into the additional data structure of the initial proposal; therefore, the target proposal can include both the transaction topology graph and the first block hash.

[0145] S403 broadcasts the target proposal in the blockchain network, enabling the nodes in the blockchain network to construct the first vote on the target proposal.

[0146] Since each node constructs the first vote result regarding the target proposal in the same way, the following explanation uses the k-th node in the blockchain network as an example to illustrate the construction method of the first vote result; where k is a positive integer, less than or equal to the number of nodes in the blockchain network, and the k-th node may be the master node or any other node besides the master node, without limitation. Specifically, the method by which the k-th node in the blockchain network constructs the first vote result regarding the target proposal may include the following steps s11-s16:

[0147] s11 executes N transactions from the target proposal to obtain the transaction execution results. Specifically, the k-th node can obtain the transaction topology graph from the target proposal and execute N transactions according to the transaction execution order indicated by the transaction topology graph. This ensures that the order in which the k-th node executes the N transactions is the same as the order in which the master node executes the N transactions, avoiding different transaction execution results due to different execution order, and thus preventing misjudgment of the voting results based on the transaction execution results.

[0148] In step s12, a vote is generated on the target proposal based on the transaction execution results to indicate whether the corresponding node supports or opposes the target proposal. Specifically, since the target proposal includes a first block hash, which is obtained by hashing the execution results of N transactions after the master node executes them, the k-th node, when executing step s12, can hash the transaction execution results to obtain a second block hash and perform a consistency check between the second block hash and the first block hash in the target proposal, i.e., determine whether the second block hash and the first block hash are the same. If the second block hash and the first block hash pass the consistency check (i.e., the second block hash and the first block hash are the same), a support vote can be cast for the target proposal, and this support vote can be represented using the second block hash (first block hash). If the second block hash and the first block hash fail the consistency check (i.e., the second block hash and the first block hash are different), a opposition vote can be cast for the target proposal, and this opposition vote can be represented using a specific value (such as NilHash).

[0149] It should be noted that if the hash of the second block and the hash of the first block pass the consistency check, the k-th node can directly cast a support vote for the target proposal as a proposal vote. Alternatively, to avoid misjudging the consistency between the hash of the second block and the hash of the first block due to tampering with the target appended data, and to further improve the accuracy of voting, the k-th node can also identify a specific transaction among the N transactions and construct reference appended data using the transaction identifier of the identified specific transaction. Based on the reference appended data, the correctness of the target appended data in the target proposal is verified. Specifically, a consistency check can be performed on the reference appended data and the target appended data. If the reference appended data and the target appended data are consistent (i.e., the same), the correctness of the target appended data can be determined to have passed the verification (i.e., the target appended data is correct); otherwise, the correctness of the target appended data can be determined to have failed the verification (i.e., the target appended data is incorrect). Furthermore, if the correctness of the target appended data passes the verification, the step of casting a support vote for the target proposal as a proposal vote is triggered; if the correctness of the target appended data fails the verification, the step of casting a negative vote for the target proposal as a proposal vote is executed.

[0150] Alternatively, another implementation of step s12 can be: obtaining the execution result generated by the master node executing N transactions as the target execution result, and performing a consistency check on the target execution result and the transaction execution result (i.e., the result generated by the k-th node executing N transactions). If the consistency check passes, a support vote is cast for the target proposal as a proposal vote; otherwise, a dissent vote is cast for the target proposal as a proposal vote.

[0151] s13, the transaction indicated by the transaction identifier in the target additional data in the target proposal is identified as the specific transaction.

[0152] s14, Detect the voting qualification of the k-th node to vote for the identified specific transaction. Specifically, if the target additional data includes at least one identifier group, and an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group; then the specific implementation of step s14 can be: obtain configuration information, which includes: a group field and at least one node field; the group field stores at least one transaction group, one transaction group corresponds to one node field, and any node field stores a list of nodes configured for the corresponding transaction group, the node list including at least one node identifier. Iterate through each identifier group in the target supplementary data and obtain the node list from the node field corresponding to the transaction group in the currently iterated identifier group from the configuration information; if the obtained node list includes the node identifier of the k-th node, then the k-th node is determined to be a specific node, that is, the k-th node has the voting qualification to vote for the identified specific transaction; if the obtained node list does not include the node identifier of the k-th node, continue iterating until each identifier group has been iterated and it is determined that the k-th node does not have the voting qualification.

[0153] Optionally, the k-th node may also obtain node-specified information, which is used to specify at least one node, thereby directly detecting whether the k-th node is included among the nodes indicated by the node-specified information. If it is included, it is determined that the k-th node has the voting qualification to vote for the identified specific transaction; otherwise, it is determined that the k-th node does not have the voting qualification to vote for the identified specific transaction.

[0154] s15, if the k-th node is detected to be eligible to vote, a transaction ticket is generated based on the target supplementary data, and the generated proposal ticket and transaction ticket are used to construct the first voting result. Specifically, generating the transaction ticket based on the target supplementary data can be done by: directly using the target supplementary data as the transaction ticket; or, performing a hash operation on the transaction identifier in the target supplementary data to obtain a transaction hash value, and then using the transaction hash value as the transaction ticket. This method protects the transaction identifier of a specific transaction from being leaked, improving information security. Furthermore, constructing the first voting result using the generated proposal ticket and transaction ticket can be done by: combining the generated proposal ticket and transaction ticket, and using the combined result as the first voting result; or, signing the combined result to obtain the first voting result. For example, suppose the target supplementary data includes multiple identifier groups, and each identifier group's transaction identifier can be used to calculate a transaction ticket, such as Key1Hash, Key2Hash, etc., then the first voting result can be exemplarily described as follows: Figure 5a As shown.

[0155] s16, if it is detected that the k-th node is not eligible to vote, then the generated proposal vote is used to construct the first voting result. Specifically, the generated proposal vote can be used as the first voting result; or, the generated proposal vote can be signed to obtain the first voting result, such as... Figure 5a As shown.

[0156] S404 collects the first vote results constructed by each node.

[0157] S405, in the first voting results collected, the number of proposal votes used to support the target proposal is counted to obtain the first vote count; and, in the first voting results collected, the number of first voting results including transaction votes is counted to obtain the second vote count.

[0158] S406, based on the first vote count and the second vote count, constructs a second voting result, which is used to indicate whether N transactions are supported or opposed to pass the consensus.

[0159] In the specific implementation, the master node can determine the first threshold quantity, which refers to the minimum number of proposal votes that need to be collected to support the target proposal before the target proposal is confirmed to pass consensus. Specifically, the first threshold quantity can be preset based on empirical values ​​or actual needs, or it can be dynamically determined based on the 3f+1 rule. Specifically, 3f+1 can be set to be less than or equal to the number of consensus nodes in the blockchain network, thereby solving for the maximum value of f. The difference between the number of consensus nodes and the maximum value of f is taken as the first threshold quantity.

[0160] Furthermore, the master node can compare the first number of votes with the first threshold number. When the first number of votes is less than the first threshold number, a second voting result can be constructed to oppose N transactions passing the consensus. When the first number of votes is greater than or equal to the first threshold number, a second threshold number can be determined. The second threshold number refers to the minimum number of designated nodes that need to endorse the identified specific transaction. This second threshold number can be preset based on empirical values ​​or actual needs, or it can be dynamically determined based on the 3f+1 rule. Specifically, 3f+1 can be set to be less than or equal to the number of designated nodes to solve for the maximum value of f. The difference between the number of designated nodes and the maximum value of f is taken as the second threshold number.

[0161] Furthermore, the master node can compare the second vote count with the second threshold count. If the second vote count is greater than or equal to the second threshold count, a second vote result can be constructed to support N transactions passing the consensus; if the second vote count is less than the second threshold count, a second vote result can be constructed to oppose N transactions passing the consensus. It should be noted that if the number of second votes is less than the second threshold, the master node can directly construct a second vote result to oppose the consensus of N transactions. Alternatively, considering that the number of second votes is less than the second threshold, it may be due to the small number of first votes collected so that the number of second votes is low. In reality, there may be enough nodes constructing first vote results that include transaction votes. Based on this, to improve the accuracy of voting, if the number of second votes is less than the second threshold, the master node can start a timer. When the timer's duration exceeds the duration threshold, the number of first vote results containing transaction votes is counted again from the collected first vote results to obtain the number of third votes. If the number of third votes is greater than or equal to the second threshold, a second vote result to support the consensus of the N transactions is constructed. If the number of third votes is less than the second threshold, the step of constructing a second vote result to oppose the consensus of N transactions is triggered.

[0162] S407 broadcasts the constructed second voting result in the blockchain network and receives the second voting result broadcast by other nodes in the blockchain network.

[0163] S408 determines the consensus result of N transactions based on the collected second vote results.

[0164] The collected second voting results include: the second voting results constructed by the master node and the received voting results. Specifically, the master node can count the number of second voting results used to support the consensus of N transactions from the collected second voting results to obtain the target number of votes; and determine the third threshold number. The third threshold number refers to the minimum number of second voting results that need to be collected to support the consensus of N transactions before determining that N transactions have passed the consensus. The method for determining the third threshold number can be similar to the method for determining the first threshold number mentioned above, and will not be elaborated here. Furthermore, if the target number of votes is less than the third threshold number, it can be determined that N transactions have not passed the consensus, thereby generating a consensus result of N transactions; if the target number of votes is greater than or equal to the third threshold number, it can be determined that N transactions have passed the consensus, thereby generating a consensus result of N transactions.

[0165] Optionally, if the consensus result indicates that N transactions failed to pass consensus, the master node can prune the N transactions to obtain remaining transactions, which do not include the identified specific transactions. A new proposal is then constructed using these remaining transactions, and consensus processing is performed on the new proposal, thereby increasing the probability that the remaining transactions will pass consensus. The master node can prune the N transactions to obtain remaining transactions in the following ways: directly deleting the identified specific transactions from the N transactions; or, considering that the execution order of transactions may cause later-executed transactions to depend on the execution results of earlier-executed transactions, the master node can obtain a transaction topology graph. Based on this graph, the identified specific transactions and all transactions whose execution order follows the identified specific transactions are considered as target transactions to be deleted, and these target transactions are deleted from the N transactions to obtain the remaining transactions. See, for example... Figure 5b As shown: Suppose there are N transactions: Tx1, Tx2, Tx3, Tx4, Tx5, and Tx6; where Tx3 and Tx4 are specific transactions, that is, Tx1, Tx2, Tx5, and Tx6 are ordinary transactions. The transaction topology diagram indicates that the execution order of Tx6 is after the execution order of Tx3, and the execution order of Tx5 is after the execution order of both Tx3 and Tx4. Therefore, Tx3-Tx6 can all be regarded as target transactions to be deleted, thereby deleting Tx3-Tx6 from Tx1-Tx6, and obtaining the remaining transactions (Tx1 and Tx2).

[0166] This embodiment of the application allows a node in the blockchain network to obtain N transactions to be reached through consensus, automatically identify a specific transaction among the N transactions, construct target supplementary data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target supplementary data and the N transactions. The target proposal is then broadcast in the blockchain network, allowing all nodes in the blockchain network to vote on the target proposal. During the voting process, designated nodes can also generate transaction tickets based on the target supplementary data to indicate their agreement with the identified specific transaction. This enables each node to construct a first voting result regarding the target proposal. Furthermore, by collecting the first voting results constructed by each node, a consensus result for the N transactions is determined based on the collected first voting results. Therefore, this embodiment of the application allows nodes in the blockchain network to complete the identification and voting of specific transactions, simplifying the consensus processing flow for specific transactions. This eliminates the need for business parties to participate in the entire consensus processing flow, thereby reducing the complexity of business parties' processing and improving the availability of the blockchain network.

[0167] In practical applications, the above Figure 2 and Figure 4The illustrated method implementation can be applied to any consensus algorithm, such as PoW (Proof of Work), PoS (Proof of Stake), and BFT (Byzantine Fault Tolerance) consensus algorithms. Figure 2 and Figure 4 The method embodiment shown does not adjust the consensus process corresponding to the consensus algorithm (the consensus process has been rigorously verified, and modification may lead to algorithm vulnerabilities). The main modification is to the consensus processing logic.

[0168] For example, for BFT-type consensus algorithms, the standard processing procedure is a three-phase consensus process, such as... Figure 6a As shown: The master node can retrieve N transactions from the transaction pool and execute them, thereby constructing a transaction topology graph and generating a proposal, which is then broadcast. Upon receiving the proposal, slave node 1 (peer1) can execute N transactions according to the transaction topology graph, determine whether to support the proposal based on the execution results, construct a first voting result, and broadcast it. Further, it can aggregate the first voting results and construct a second voting result based on the number of proposal votes in the aggregated first voting results, and broadcast the second voting result. Even further, it can aggregate the second voting results and determine the consensus result of the N transactions based on the aggregated second voting results. Figure 6a The processing logic for peer 2 and peer 3 is the same as that for peer 1, and will not be elaborated here.

[0169] When the consensus processing method based on a blockchain network proposed in this application is applied to this BFT-type consensus algorithm, the corresponding modifications can be found in [reference needed]. Figure 6b As shown in the dashed box, it mainly includes three parts: changes in the proposal content, adjustments to the voting content in the first stage, and adjustments to the voting process in the second stage. Among them, (1) changes in the proposal content include: identifying a specific transaction among N transactions and filling the transaction identifier of the specific transaction into the additional data structure in the proposal. (2) Adjustments to the voting content in the first stage include: determining whether to construct transaction tickets based on the configuration information so that the constructed first voting result includes transaction tickets. (3) Adjustments to the voting process in the second stage include: constructing a second voting result based on the number of proposal tickets and the number of transaction tickets in the aggregated first voting result.

[0170] The following is combined with Figure 6c The flowchart shown illustrates the consensus process of the modified BFT-type consensus algorithm:

[0171] (I) Master Node Proposal Process:

[0172] The master node can retrieve N transactions from the transaction pool, such as six transactions: Tx1 (transaction 1), Tx2 (transaction 2), Tx3 (transaction 3), Tx4 (transaction 4), Tx5 (transaction 5), and Tx6 (transaction 6). Among these, specific transactions include Tx3, Tx5, and Tx6, while ordinary transactions include Tx1-Tx5. The master node schedules and executes each transaction in parallel to obtain the execution result of each transaction. It constructs a transaction topology graph and performs a hash operation on the execution results of the N transactions to obtain the hash of the first block. The master node constructs a proposal using the transaction topology graph, the hash of the first block, and the information of the N transactions. Based on the transaction read / write set and transaction information of each transaction, it identifies specific transactions among the N transactions, adds the transaction identifier of the identified specific transactions to the additional data structure in the proposal, and then broadcasts the proposal to the slave nodes.

[0173] (II) First-round voting process from nodes:

[0174] A slave node can receive proposals, execute all transactions based on the transaction topology graph, obtain transaction execution results, vote on proposals according to the transaction execution results to generate proposal votes, and determine whether the current node votes separately on a specific transaction. If so, it generates transaction votes, and then constructs the first voting result using the proposal votes and transaction votes and broadcasts it to other nodes. Further details on the processing logic for a slave node generating the first voting result can be found in [link to relevant documentation]. Figure 6d As shown: A node can receive proposals, execute transactions based on the transaction topology graph, obtain transaction execution results, generate a second block hash based on the transaction execution results, and determine whether the second block hash is consistent with the first block hash in the proposal; if not, a first voting result is generated, which includes proposal votes indicating opposition. If yes, a specific transaction among N transactions is identified based on the configuration information, and the data in the additional data structure (i.e., the target additional data) is checked for correctness based on the identification result. If incorrect, a first voting result is generated, which includes proposal votes indicating opposition; if correct, it is determined whether the current node votes separately on the specific transaction; if not, a first voting result is generated, which includes proposal votes indicating support; if yes, a hash operation is performed on the transaction identifier of the specific transaction (which can be implemented using a Merkle tree) to obtain transaction votes, thereby generating a first voting result, which includes proposal votes indicating support and transaction votes.

[0175] (III) Second-round voting process from nodes:

[0176] The system aggregates the first voting results from each node and verifies the number of proposal votes and transaction votes used to indicate support in the aggregated first voting results. If both the number of proposal votes and transaction votes used to indicate support meet the quantity requirements, a second voting result to indicate support can be generated; otherwise, further analysis is performed. Specifically, for example... Figure 6e As shown: From the node, it can verify whether the number of votes representing support in the first aggregated voting result meets the quantity requirement (i.e., greater than or equal to the first threshold). If not, a second vote representing opposition is generated. If yes, it can verify whether the number of transaction votes in the first aggregated voting result meets the quantity requirement (i.e., greater than or equal to the second threshold). If yes, a second vote representing support is generated. If not, a timer is started. After the timer times out (i.e., the timeout duration exceeds the duration threshold), it re-evaluates whether the number of transaction votes in the first aggregated voting result meets the quantity requirement. If yes, a second vote representing support is generated. If not, a second vote representing opposition is generated.

[0177] Optional, such as Figure 6e As shown: If N transactions fail to pass consensus based on the second voting result, N transactions can be pruned according to the transaction topology and specific transactions to obtain the remaining transactions after pruning. The remaining transactions are then recalculated to generate new block hashes. A new proposal is constructed using the new block hashes and the remaining transactions, and consensus processing is performed on the new proposal. The new proposal does not contain the specific transactions.

[0178] As can be seen from the above description, the embodiments of this application can simplify the consensus processing flow for specific transactions, so that the entire consensus processing flow does not require the participation of the business party, thereby reducing the complexity of the business party's processing and improving the availability of the blockchain network.

[0179] Based on the description of the above method embodiments, this application also discloses a consensus processing device based on a blockchain network; the consensus processing device based on a blockchain network can be a computer program (including one or more instructions) running on a computer device, and the consensus processing device based on a blockchain network can execute each step in the above method flow. Please refer to... Figure 7 The consensus processing device based on the blockchain network can operate the following units:

[0180] Processing unit 701 is used to acquire N transactions to be agreed upon and identify a specific transaction among the N transactions; N is a positive integer, and the specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before consensus is reached;

[0181] The processing unit 701 is further configured to construct target additional data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target additional data and the N transactions;

[0182] Consensus unit 702 is used to broadcast the target proposal in the blockchain network, so that each node in the blockchain network constructs a first voting result about the target proposal; wherein any first voting result includes: a proposal vote generated by voting on the target proposal, and the voting result constructed by the designated node also includes: a transaction vote generated based on the target additional data, the transaction vote indicating that the designated node agrees with the identified specific transaction;

[0183] The consensus unit 702 is also used to collect the first voting results constructed by each node, and to determine the consensus result of the N transactions based on the collected first voting results.

[0184] In one implementation, the processing unit 701, when identifying a specific transaction among the N transactions, may specifically be used to:

[0185] Obtain configuration information, which includes: at least one trading group configured for a specific exchange and a trading identification strategy under each trading group; any trading identification strategy is used to indicate: the attribute information that a specific transaction under the corresponding trading group should possess;

[0186] For the nth transaction among the N transactions, traverse each transaction group in the configuration information, and take the transaction identification strategy under the currently traversed ith transaction group as the ith transaction identification strategy; where n∈[1,N], and i is a positive integer less than or equal to the number of transaction groups;

[0187] If the nth transaction possesses the attribute information indicated by the i-th transaction identification strategy, then the nth transaction is identified as a specific transaction under the i-th transaction group, and the process continues to traverse each transaction group in the configuration information.

[0188] If the nth transaction does not possess the attribute information indicated by the ith transaction identification strategy, then the process continues to traverse each transaction group in the configuration information.

[0189] In another embodiment, the configuration information includes a group field, which stores at least one transaction group;

[0190] The i-th transaction identification strategy under the i-th transaction group includes: a type field and M information fields, where M is a positive integer;

[0191] The value of the type field is used to indicate the M attribute types and the logical operation relationship between the M attribute types; one attribute type corresponds to one information field, and the value of any information field includes: the attribute information that a specific transaction under the i-th transaction group should have under the corresponding attribute type;

[0192] Wherein, when the logical operation relationship between the M attribute types is an AND relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under each of the M attribute types; when the logical operation relationship between the M attribute types is an OR relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under any one of the M attribute types.

[0193] In another implementation, the M attribute types include at least one of the following: a first contract name type, a second contract name type, and an organization name type; wherein:

[0194] The attribute information under the first contract name type includes the first contract name, which refers to the contract name in the transaction read / write set generated by executing the transaction;

[0195] The attribute information under the second contract name type includes the second contract name, which refers to the name of the smart contract that is directly invoked when the transaction is executed;

[0196] The attribute information under the organization name type includes the organization name, which refers to the name of the sender of the transaction.

[0197] In another embodiment, when processing unit 701 constructs target additional data using the transaction identifier of the identified specific transaction, it may specifically be used to:

[0198] Obtain the transaction group for each specific transaction identified;

[0199] Based on the transaction group of each specific transaction, the transaction identifiers of each specific transaction are grouped to obtain at least one identifier group; wherein, an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group, and the transaction groups in different identifier groups are different;

[0200] Using the at least one identifier group, construct the target additional data.

[0201] In another embodiment, when processing unit 701 generates a target proposal using the target additional data and the N transactions, it may specifically be used to:

[0202] An initial proposal is generated using the N transactions, and the initial proposal includes an additional data structure;

[0203] The target additional data is populated into the additional data structure in the initial proposal to obtain the target proposal.

[0204] In another implementation, the consensus unit 702, when constructing the first voting result regarding the target proposal, may specifically be used for:

[0205] Execute N transactions in the target proposal to obtain transaction execution results; and vote on the target proposal based on the transaction execution results to generate proposal votes, which are used to instruct the corresponding nodes to support or oppose the target proposal.

[0206] The transaction indicated by the transaction identifier in the target additional data of the target proposal is identified as a specific transaction; and the voting qualification of the k-th node to vote in favor of the identified specific transaction is detected.

[0207] If the kth node is detected to have the voting qualification, a transaction ticket is generated based on the target additional data, and the generated proposal ticket and transaction ticket are used to construct the first voting result; if the kth node is detected to not have the voting qualification, the generated proposal ticket is used to construct the first voting result.

[0208] Where k is a positive integer, and is less than or equal to the number of nodes in the blockchain network.

[0209] In another embodiment, the target additional data includes the at least one identifier group, wherein an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group;

[0210] Accordingly, when the consensus unit 702 is used to detect the voting eligibility of the k-th node to vote in favor of the identified specific transaction, it can be specifically used for:

[0211] Obtain configuration information, which includes a group field and at least one node field; the group field stores at least one transaction group, one transaction group corresponds to one node field, and any node field stores a list of nodes configured for the corresponding transaction group, the list of nodes including at least one node identifier;

[0212] Iterate through each identifier group in the target additional data, and obtain the node list in the node field corresponding to the transaction group in the currently traversed identifier group from the configuration information;

[0213] If the obtained list of nodes includes the node identifier of the kth node, then the kth node is determined to have the voting qualification to vote in favor of the identified specific transaction.

[0214] If the obtained list of nodes does not include the node identifier of the kth node, the traversal continues until all the identifier groups have been traversed, and it is determined that the kth node does not have the qualification to vote.

[0215] In another implementation, the target proposal further includes: a transaction topology graph and a first block hash; the transaction topology graph is used to indicate the transaction execution order among the N transactions, and the first block hash is obtained by hashing the execution results of the N transactions after they are executed; wherein the k-th node executes the N transactions according to the transaction execution order indicated by the transaction topology graph;

[0216] Accordingly, when consensus unit 702 is used to vote on the target proposal based on the transaction execution result to generate proposal votes, it can be specifically used for:

[0217] The transaction execution result is hashed to obtain the second block hash;

[0218] Perform a consistency check between the hash of the second block and the hash of the first block in the target proposal;

[0219] If the second block hash and the first block hash pass the consistency check, then vote in favor of the target proposal as a proposal vote;

[0220] If the second block hash and the first block hash fail the consistency check, then a vote against the target proposal is cast as a proposal vote.

[0221] In another implementation, if the second block hash and the first block hash pass the consistency check, the consensus unit 702 can also be used for:

[0222] Identify a specific transaction among the N transactions, and construct reference supplementary data using the transaction identifier of the identified specific transaction;

[0223] Based on the aforementioned reference supplementary data, the correctness of the target supplementary data in the target proposal is verified.

[0224] If the correctness of the target supplementary data passes the verification, the step of casting a support vote for the target proposal as a proposal vote is triggered; if the correctness of the target supplementary data fails the verification, a negative vote is cast for the target proposal as a proposal vote.

[0225] In another implementation, when the consensus unit 702 is used to generate a transaction ticket based on the target additional data, it may specifically be used to:

[0226] Perform a hash operation on the transaction identifier in the target additional data to obtain the transaction hash value;

[0227] The transaction hash value is used as the transaction ticket.

[0228] In another implementation, when consensus unit 702 is used to determine the consensus result of the N transactions based on the collected first voting results, it can specifically be used for:

[0229] In the first voting results collected, the number of proposal votes used to support the target proposal is counted to obtain the first vote count; and in the first voting results collected, the number of first voting results containing the transaction vote is counted to obtain the second vote count;

[0230] Based on the first number of votes and the second number of votes, a second voting result is constructed. The constructed second voting result is used to indicate whether to support or oppose the N transactions through consensus.

[0231] The constructed second voting result is broadcast in the blockchain network, and the second voting result broadcast by other nodes in the blockchain network is received.

[0232] Based on the collected second voting results, the consensus result of the N transactions is determined; wherein, the collected second voting results include: the constructed second voting results and the received voting results.

[0233] In another implementation, when the consensus unit 702 is used to construct a second voting result based on the first number of votes and the second number of votes, it can specifically be used to:

[0234] A first threshold number is determined, which refers to the minimum number of proposal votes required to support the target proposal before the target proposal is determined to pass consensus.

[0235] When the first number of votes is less than the first threshold number, a second voting result is constructed to oppose the consensus of the N transactions.

[0236] When the first number of votes is greater than or equal to the first threshold number, a second threshold number is determined. The second threshold number refers to the minimum number of designated nodes that need to endorse the identified specific transaction.

[0237] If the second number of votes is greater than or equal to the second threshold number, a second voting result is constructed to support the consensus of the N transactions; if the second number of votes is less than the second threshold number, a second voting result is constructed to oppose the consensus of the N transactions.

[0238] In another implementation, if the second number of votes is less than the second threshold number, the consensus unit 702 can also be used for:

[0239] Start the timer used for timing;

[0240] When the duration of the timer exceeds the duration threshold, the number of first voting results containing the transaction votes is counted again from the collected first voting results to obtain the third voting count;

[0241] If the number of third votes is greater than or equal to the number of the second threshold, a second voting result is constructed to support the consensus of the N transactions; if the number of third votes is less than the number of the second threshold, the step of constructing a second voting result to oppose the consensus of the N transactions is triggered.

[0242] In another implementation, after determining the consensus result of the N transactions, the consensus unit 702 can also be used for:

[0243] If the consensus result indicates that the N transactions have failed to pass the consensus, then the N transactions are pruned to obtain the remaining transactions, which do not include the identified specific transactions;

[0244] A new proposal is constructed using the remaining transactions, and consensus processing is performed on the new proposal.

[0245] According to another embodiment of this application, Figure 7 The units in the blockchain-based consensus processing device shown can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the blockchain-based consensus processing device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0246] According to another embodiment of this application, a computer program (including one or more instructions) capable of performing the steps involved in the above-described method can be run on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), to construct a system such as... Figure 7The diagram illustrates a consensus processing device based on a blockchain network, and the various methods implemented in the embodiments of this application. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0247] It is worth noting that, in the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program with a predetermined function, which works together 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 contain a portion of the overall module or unit's functionality.

[0248] This embodiment of the application allows a node in the blockchain network to obtain N transactions to be reached through consensus, automatically identify a specific transaction among the N transactions, construct target supplementary data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target supplementary data and the N transactions. The target proposal is then broadcast in the blockchain network, allowing all nodes in the blockchain network to vote on the target proposal. During the voting process, designated nodes can also generate transaction tickets based on the target supplementary data to indicate their agreement with the identified specific transaction. This enables each node to construct a first voting result regarding the target proposal. Furthermore, by collecting the first voting results constructed by each node, a consensus result for the N transactions is determined based on the collected first voting results. Therefore, this embodiment of the application allows nodes in the blockchain network to complete the identification and voting of specific transactions, simplifying the consensus processing flow for specific transactions. This eliminates the need for business parties to participate in the entire consensus processing flow, thereby reducing the complexity of business parties' processing and improving the availability of the blockchain network.

[0249] Based on the description of the above method and apparatus embodiments, this application also provides a computer device. Please refer to... Figure 8The computer device includes at least a processor 801, an input interface 802, an output interface 803, and a computer storage medium 804. The processor 801, input interface 802, output interface 803, and computer storage medium 804 within the computer device can be connected via a bus or other means. The computer storage medium 804 can be stored in the computer device's memory. The computer storage medium 804 is used to store a computer program, which includes one or more instructions. The processor 801 is used to execute one or more instructions from the computer program stored in the computer storage medium 804. The processor 801 (or CPU (Central Processing Unit)) is the computing and control core of the computer device, adapted to implement one or more instructions, specifically adapted to load and execute one or more instructions to achieve a corresponding method flow or function.

[0250] In one embodiment, the processor 801 described in this application embodiment can be used to perform a series of consensus processes on a specific transaction, specifically including: acquiring N transactions to be agreed upon, and identifying a specific transaction among the N transactions; N is a positive integer, and the specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before reaching consensus; constructing target additional data using the transaction identifier of the identified specific transaction, and generating a target proposal using the target additional data and the N transactions; broadcasting the target proposal in the blockchain network, so that each node in the blockchain network constructs a first voting result regarding the target proposal; wherein any first voting result includes: a proposal vote generated by voting on the target proposal, and the voting result constructed by the designated node also includes: a transaction vote generated based on the target additional data, the transaction vote indicating that the designated node recognizes the identified specific transaction; collecting the first voting results constructed by each node, and determining the consensus result of the N transactions based on the collected first voting results, etc.

[0251] This application embodiment also provides a computer storage medium (Memory), which is a memory device in a computer device used to store computer programs and data. It is understood that the computer storage medium here can include both the built-in storage medium in the computer device and extended storage media supported by the computer device. The computer storage medium provides storage space that stores the operating system of the computer device. Furthermore, the storage space also stores a computer program, which includes one or more instructions suitable for loading and execution by the processor 801. These instructions can be one or more program codes. It should be noted that the computer storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer storage medium located remotely from the aforementioned processor.

[0252] In one embodiment, a processor may load and execute one or more instructions stored in a computer storage medium to implement the corresponding steps in the above method embodiments; specifically, one or more instructions in the computer storage medium may be loaded and executed by the processor in the following steps:

[0253] Obtain N transactions awaiting consensus and identify a specific transaction among the N transactions; N is a positive integer, and the specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before reaching consensus;

[0254] Target supplementary data is constructed using the transaction identifiers of the identified specific transactions, and a target proposal is generated using the target supplementary data and the N transactions;

[0255] The target proposal is broadcast in the blockchain network, causing each node in the blockchain network to construct a first voting result regarding the target proposal; wherein any first voting result includes: a proposal vote generated by voting on the target proposal, and the voting result constructed by the designated node also includes: a transaction vote generated based on the target additional data, the transaction vote indicating that the designated node agrees with the identified specific transaction;

[0256] Collect the first voting results constructed by each node, and determine the consensus result of the N transactions based on the collected first voting results.

[0257] In one implementation, when identifying a specific transaction among the N transactions, the one or more instructions can be loaded and executed by the processor:

[0258] Obtain configuration information, which includes: at least one trading group configured for a specific exchange and a trading identification strategy under each trading group; any trading identification strategy is used to indicate: the attribute information that a specific transaction under the corresponding trading group should possess;

[0259] For the nth transaction among the N transactions, traverse each transaction group in the configuration information, and take the transaction identification strategy under the currently traversed ith transaction group as the ith transaction identification strategy; where n∈[1,N], and i is a positive integer less than or equal to the number of transaction groups;

[0260] If the nth transaction possesses the attribute information indicated by the i-th transaction identification strategy, then the nth transaction is identified as a specific transaction under the i-th transaction group, and the process continues to traverse each transaction group in the configuration information.

[0261] If the nth transaction does not possess the attribute information indicated by the ith transaction identification strategy, then the process continues to traverse each transaction group in the configuration information.

[0262] In another embodiment, the configuration information includes a group field, which stores at least one transaction group;

[0263] The i-th transaction identification strategy under the i-th transaction group includes: a type field and M information fields, where M is a positive integer;

[0264] The value of the type field is used to indicate the M attribute types and the logical operation relationship between the M attribute types; one attribute type corresponds to one information field, and the value of any information field includes: the attribute information that a specific transaction under the i-th transaction group should have under the corresponding attribute type;

[0265] Wherein, when the logical operation relationship between the M attribute types is an AND relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under each of the M attribute types; when the logical operation relationship between the M attribute types is an OR relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under any one of the M attribute types.

[0266] In another implementation, the M attribute types include at least one of the following: a first contract name type, a second contract name type, and an organization name type; wherein:

[0267] The attribute information under the first contract name type includes the first contract name, which refers to the contract name in the transaction read / write set generated by executing the transaction;

[0268] The attribute information under the second contract name type includes the second contract name, which refers to the name of the smart contract that is directly invoked when the transaction is executed;

[0269] The attribute information under the organization name type includes the organization name, which refers to the name of the sender of the transaction.

[0270] In another implementation, when constructing target additional data using the transaction identifier of a specific identified transaction, the one or more instructions may be loaded and executed by the processor:

[0271] Obtain the transaction group for each specific transaction identified;

[0272] Based on the transaction group of each specific transaction, the transaction identifiers of each specific transaction are grouped to obtain at least one identifier group; wherein, an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group, and the transaction groups in different identifier groups are different;

[0273] Using the at least one identifier group, construct the target additional data.

[0274] In another implementation, when generating the target proposal using the target additional data and the N transactions, the one or more instructions can be loaded and executed by the processor:

[0275] An initial proposal is generated using the N transactions, and the initial proposal includes an additional data structure;

[0276] The target additional data is populated into the additional data structure in the initial proposal to obtain the target proposal.

[0277] In another implementation, when constructing the first voting result regarding the target proposal, the one or more instructions may be loaded and executed by the processor:

[0278] Execute N transactions in the target proposal to obtain transaction execution results; and vote on the target proposal based on the transaction execution results to generate proposal votes, which are used to instruct the corresponding nodes to support or oppose the target proposal.

[0279] The transaction indicated by the transaction identifier in the target additional data of the target proposal is identified as a specific transaction; and the voting qualification of the k-th node to vote in favor of the identified specific transaction is detected.

[0280] If the kth node is detected to have the voting qualification, a transaction ticket is generated based on the target additional data, and the generated proposal ticket and transaction ticket are used to construct the first voting result; if the kth node is detected to not have the voting qualification, the generated proposal ticket is used to construct the first voting result.

[0281] Where k is a positive integer, and is less than or equal to the number of nodes in the blockchain network.

[0282] In another embodiment, the target additional data includes the at least one identifier group, wherein an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group;

[0283] Accordingly, when detecting the voting eligibility of the k-th node to vote in favor of the identified specific transaction, one or more instructions can be loaded and executed by the processor:

[0284] Obtain configuration information, which includes a group field and at least one node field; the group field stores at least one transaction group, one transaction group corresponds to one node field, and any node field stores a list of nodes configured for the corresponding transaction group, the list of nodes including at least one node identifier;

[0285] Iterate through each identifier group in the target additional data, and obtain the node list in the node field corresponding to the transaction group in the currently traversed identifier group from the configuration information;

[0286] If the obtained list of nodes includes the node identifier of the kth node, then the kth node is determined to have the voting qualification to vote in favor of the identified specific transaction.

[0287] If the obtained list of nodes does not include the node identifier of the kth node, the traversal continues until all the identifier groups have been traversed, and it is determined that the kth node does not have the qualification to vote.

[0288] In another implementation, the target proposal further includes: a transaction topology graph and a first block hash; the transaction topology graph is used to indicate the transaction execution order among the N transactions, and the first block hash is obtained by hashing the execution results of the N transactions after they are executed; wherein the k-th node executes the N transactions according to the transaction execution order indicated by the transaction topology graph;

[0289] Accordingly, when voting on the target proposal based on the transaction execution result to generate a proposal vote, the one or more instructions can be loaded and executed by the processor:

[0290] The transaction execution result is hashed to obtain the second block hash;

[0291] Perform a consistency check between the hash of the second block and the hash of the first block in the target proposal;

[0292] If the second block hash and the first block hash pass the consistency check, then vote in favor of the target proposal as a proposal vote;

[0293] If the second block hash and the first block hash fail the consistency check, then a vote against the target proposal is cast as a proposal vote.

[0294] In another implementation, if the second block hash and the first block hash pass the consistency check, then the one or more instructions can be loaded and executed by the processor:

[0295] Identify a specific transaction among the N transactions, and construct reference supplementary data using the transaction identifier of the identified specific transaction;

[0296] Based on the aforementioned reference supplementary data, the correctness of the target supplementary data in the target proposal is verified.

[0297] If the correctness of the target supplementary data passes the verification, the step of casting a support vote for the target proposal as a proposal vote is triggered; if the correctness of the target supplementary data fails the verification, a negative vote is cast for the target proposal as a proposal vote.

[0298] In another implementation, when generating a transaction ticket based on the target additional data, the one or more instructions can be loaded and executed by the processor:

[0299] Perform a hash operation on the transaction identifier in the target additional data to obtain the transaction hash value;

[0300] The transaction hash value is used as the transaction ticket.

[0301] In another implementation, when determining the consensus result of the N transactions based on the collected first voting results, the one or more instructions can be loaded and executed by the processor:

[0302] In the first voting results collected, the number of proposal votes used to support the target proposal is counted to obtain the first vote count; and in the first voting results collected, the number of first voting results containing the transaction vote is counted to obtain the second vote count;

[0303] Based on the first number of votes and the second number of votes, a second voting result is constructed. The constructed second voting result is used to indicate whether to support or oppose the N transactions through consensus.

[0304] The constructed second voting result is broadcast in the blockchain network, and the second voting result broadcast by other nodes in the blockchain network is received.

[0305] Based on the collected second voting results, the consensus result of the N transactions is determined; wherein, the collected second voting results include: the constructed second voting results and the received voting results.

[0306] In another implementation, when constructing the second voting result based on the first number of votes and the second number of votes, the one or more instructions can be loaded and executed by the processor:

[0307] A first threshold number is determined, which refers to the minimum number of proposal votes required to support the target proposal before the target proposal is determined to pass consensus.

[0308] When the first number of votes is less than the first threshold number, a second voting result is constructed to oppose the consensus of the N transactions.

[0309] When the first number of votes is greater than or equal to the first threshold number, a second threshold number is determined. The second threshold number refers to the minimum number of designated nodes that need to endorse the identified specific transaction.

[0310] If the second number of votes is greater than or equal to the second threshold number, a second voting result is constructed to support the consensus of the N transactions; if the second number of votes is less than the second threshold number, a second voting result is constructed to oppose the consensus of the N transactions.

[0311] In another implementation, if the second number of votes is less than the second threshold number, then the one or more instructions can be loaded and executed by the processor:

[0312] Start the timer used for timing;

[0313] When the duration of the timer exceeds the duration threshold, the number of first voting results containing the transaction votes is counted again from the collected first voting results to obtain the third voting count;

[0314] If the number of third votes is greater than or equal to the number of the second threshold, a second voting result is constructed to support the consensus of the N transactions; if the number of third votes is less than the number of the second threshold, the step of constructing a second voting result to oppose the consensus of the N transactions is triggered.

[0315] In another implementation, after determining the consensus result of the N transactions, the one or more instructions can be loaded and executed by the processor:

[0316] If the consensus result indicates that the N transactions have failed to pass the consensus, then the N transactions are pruned to obtain the remaining transactions, which do not include the identified specific transactions;

[0317] A new proposal is constructed using the remaining transactions, and consensus processing is performed on the new proposal.

[0318] This embodiment of the application allows a node in the blockchain network to obtain N transactions to be reached through consensus, automatically identify a specific transaction among the N transactions, construct target supplementary data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target supplementary data and the N transactions. The target proposal is then broadcast in the blockchain network, allowing all nodes in the blockchain network to vote on the target proposal. During the voting process, designated nodes can also generate transaction tickets based on the target supplementary data to indicate their agreement with the identified specific transaction. This enables each node to construct a first voting result regarding the target proposal. Furthermore, by collecting the first voting results constructed by each node, a consensus result for the N transactions is determined based on the collected first voting results. Therefore, this embodiment of the application allows nodes in the blockchain network to complete the identification and voting of specific transactions, simplifying the consensus processing flow for specific transactions. This eliminates the need for business parties to participate in the entire consensus processing flow, thereby reducing the complexity of business parties' processing and improving the availability of the blockchain network.

[0319] It should be noted that, according to one aspect of this application, a computer program product or computer program is also provided, comprising one or more instructions stored in a computer storage medium. A processor of a computer device reads one or more instructions from the computer storage medium and executes the one or more instructions, causing the computer device to perform the methods provided in various optional embodiments of the above-described method. It should be understood that the above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, equivalent variations made according to the claims of this application are still within the scope of this application.

Claims

1. A consensus processing method based on a blockchain network, characterized in that, include: Obtain N transactions awaiting consensus and identify a specific transaction among the N transactions; N is a positive integer, and the specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before reaching consensus; Target supplementary data is constructed using the transaction identifiers of the identified specific transactions, and a target proposal is generated using the target supplementary data and the N transactions; The target proposal is broadcast in the blockchain network, causing each node in the blockchain network to construct a first voting result regarding the target proposal; wherein any first voting result includes: a proposal vote generated by voting on the target proposal, and the voting result constructed by the designated node also includes: a transaction vote generated based on the target additional data, the transaction vote indicating that the designated node agrees with the identified specific transaction; Collect the first voting results constructed by each node, and determine the consensus result of the N transactions based on the collected first voting results.

2. The method as described in claim 1, characterized in that, The identification of a specific transaction among the N transactions includes: Obtain configuration information, which includes: at least one trading group configured for a specific exchange and a trading identification strategy under each trading group; any trading identification strategy is used to indicate: the attribute information that a specific transaction under the corresponding trading group should possess; For the nth transaction among the N transactions, traverse each transaction group in the configuration information, and take the transaction identification strategy under the currently traversed ith transaction group as the ith transaction identification strategy; where n∈[1,N], and i is a positive integer less than or equal to the number of transaction groups; If the nth transaction possesses the attribute information indicated by the i-th transaction identification strategy, then the nth transaction is identified as a specific transaction under the i-th transaction group, and the process continues to traverse each transaction group in the configuration information. If the nth transaction does not possess the attribute information indicated by the ith transaction identification strategy, then the process continues to traverse each transaction group in the configuration information.

3. The method as described in claim 2, characterized in that, The configuration information includes a group field, which stores at least one transaction group; The i-th transaction identification strategy under the i-th transaction group includes: a type field and M information fields, where M is a positive integer; The value of the type field is used to indicate the M attribute types and the logical operation relationship between the M attribute types; one attribute type corresponds to one information field, and the value of any information field includes: the attribute information that a specific transaction under the i-th transaction group should have under the corresponding attribute type; Wherein, when the logical operation relationship between the M attribute types is an AND relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under each of the M attribute types; when the logical operation relationship between the M attribute types is an OR relationship, the attribute information indicated by the i-th transaction identification strategy includes: the attribute information under any one of the M attribute types.

4. The method as described in claim 3, characterized in that, The M attribute types include at least one of the following: a first contract name type, a second contract name type, and an organization name type; wherein: The attribute information under the first contract name type includes the first contract name, which refers to the contract name in the transaction read / write set generated by executing the transaction; The attribute information under the second contract name type includes the second contract name, which refers to the name of the smart contract that is directly invoked when the transaction is executed; The attribute information under the organization name type includes the organization name, which refers to the name of the sender of the transaction.

5. The method as described in claim 2, characterized in that, The construction of target supplementary data using the transaction identifier of the identified specific transaction includes: Obtain the transaction group for each specific transaction identified; Based on the transaction group of each specific transaction, the transaction identifiers of each specific transaction are grouped to obtain at least one identifier group; wherein, an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group, and the transaction groups in different identifier groups are different; Using the at least one identifier group, construct the target additional data.

6. The method as described in claim 1, characterized in that, The process of generating a target proposal using the target additional data and the N transactions includes: An initial proposal is generated using the N transactions, and the initial proposal includes an additional data structure; The target additional data is populated into the additional data structure in the initial proposal to obtain the target proposal.

7. The method as described in claim 1, characterized in that, The method by which the k-th node in the blockchain network constructs the first voting result regarding the target proposal includes: Execute N transactions in the target proposal to obtain transaction execution results; and vote on the target proposal based on the transaction execution results to generate proposal votes, which are used to instruct the corresponding nodes to support or oppose the target proposal. The transaction indicated by the transaction identifier in the target additional data of the target proposal is identified as a specific transaction; and the voting qualification of the k-th node to vote in favor of the identified specific transaction is detected. If the kth node is detected to have the voting qualification, a transaction ticket is generated based on the target additional data, and the generated proposal ticket and transaction ticket are used to construct the first voting result; if the kth node is detected to not have the voting qualification, the generated proposal ticket is used to construct the first voting result. Where k is a positive integer, and is less than or equal to the number of nodes in the blockchain network.

8. The method as described in claim 7, characterized in that, The target additional data includes at least one identifier group, and an identifier group includes: a transaction group and the transaction identifiers of each specific transaction under the corresponding transaction group; The detection of the voting eligibility of the k-th node to vote in favor of the identified specific transaction includes: Obtain configuration information, which includes a group field and at least one node field; the group field stores at least one transaction group, one transaction group corresponds to one node field, and any node field stores a list of nodes configured for the corresponding transaction group, the list of nodes including at least one node identifier; Iterate through each identifier group in the target additional data, and obtain the node list in the node field corresponding to the transaction group in the currently traversed identifier group from the configuration information; If the obtained list of nodes includes the node identifier of the kth node, then the kth node is determined to have the voting qualification to vote in favor of the identified specific transaction. If the obtained list of nodes does not include the node identifier of the kth node, the traversal continues until all the identifier groups have been traversed, and it is determined that the kth node does not have the qualification to vote.

9. The method as described in claim 7, characterized in that, The target proposal also includes: a transaction topology graph and a first block hash; the transaction topology graph is used to indicate the transaction execution order among the N transactions, and the first block hash is obtained by performing a hash operation on the execution results of the N transactions after they are executed; The k-th node executes the N transactions according to the transaction execution order indicated by the transaction topology diagram; The step of voting on the target proposal based on the transaction execution result to generate proposal votes includes: The transaction execution result is hashed to obtain the second block hash; Perform a consistency check between the hash of the second block and the hash of the first block in the target proposal; If the second block hash and the first block hash pass the consistency check, then vote in favor of the target proposal as a proposal vote; If the second block hash and the first block hash fail the consistency check, then a vote against the target proposal is cast as a proposal vote.

10. The method as described in claim 9, characterized in that, If the second block hash and the first block hash pass the consistency check, the method further includes: Identify a specific transaction among the N transactions, and construct reference supplementary data using the transaction identifier of the identified specific transaction; Based on the aforementioned reference supplementary data, the correctness of the target supplementary data in the target proposal is verified. If the correctness of the target supplementary data passes the verification, the step of casting a support vote for the target proposal as a proposal vote is triggered; if the correctness of the target supplementary data fails the verification, a negative vote is cast for the target proposal as a proposal vote.

11. The method as described in claim 7, characterized in that, The generation of a transaction ticket based on the target additional data includes: Perform a hash operation on the transaction identifier in the target additional data to obtain the transaction hash value; The transaction hash value is used as the transaction ticket.

12. The method as described in claim 1, characterized in that, The consensus result for determining the N transactions based on the collected first voting results includes: In the first voting results collected, the number of proposal votes used to support the target proposal is counted to obtain the first vote count; and in the first voting results collected, the number of first voting results containing the transaction vote is counted to obtain the second vote count; Based on the first number of votes and the second number of votes, a second voting result is constructed. The constructed second voting result is used to indicate whether to support or oppose the N transactions through consensus. The constructed second voting result is broadcast in the blockchain network, and the second voting result broadcast by other nodes in the blockchain network is received. Based on the collected second voting results, the consensus result of the N transactions is determined; wherein, the collected second voting results include: the constructed second voting results and the received voting results.

13. The method as described in claim 12, characterized in that, The construction of the second voting result based on the first number of votes and the second number of votes includes: A first threshold number is determined, which refers to the minimum number of proposal votes required to support the target proposal before the target proposal is determined to pass consensus. When the first number of votes is less than the first threshold number, a second voting result is constructed to oppose the consensus of the N transactions. When the first number of votes is greater than or equal to the first threshold number, a second threshold number is determined. The second threshold number refers to the minimum number of designated nodes that need to endorse the identified specific transaction. If the second number of votes is greater than or equal to the second threshold number, a second voting result is constructed to support the consensus of the N transactions; if the second number of votes is less than the second threshold number, a second voting result is constructed to oppose the consensus of the N transactions.

14. The method as described in claim 13, characterized in that, If the second number of votes is less than the second threshold number, the method further includes: Start the timer used for timing; When the duration of the timer exceeds the duration threshold, the number of first voting results containing the transaction votes is counted again from the collected first voting results to obtain the third voting count; If the number of third votes is greater than or equal to the number of the second threshold, a second voting result is constructed to support the consensus of the N transactions; if the number of third votes is less than the number of the second threshold, the step of constructing a second voting result to oppose the consensus of the N transactions is triggered.

15. The method as described in claim 1, characterized in that, After determining the consensus result of the N transactions, the method further includes: If the consensus result indicates that the N transactions have failed to pass the consensus, then the N transactions are pruned to obtain the remaining transactions, which do not include the identified specific transactions; A new proposal is constructed using the remaining transactions, and consensus processing is performed on the new proposal.

16. A consensus processing device based on a blockchain network, characterized in that, include: The processing unit is used to acquire N transactions to be reached in consensus and identify a specific transaction among the N transactions; N is a positive integer, and the specific transaction refers to a transaction that needs to be recognized by a designated node in the blockchain network before reaching consensus; The processing unit is further configured to construct target additional data using the transaction identifier of the identified specific transaction, and generate a target proposal using the target additional data and the N transactions; A consensus unit is used to broadcast the target proposal in a blockchain network, enabling each node in the blockchain network to construct a first voting result regarding the target proposal; wherein any first voting result includes: a proposal vote generated by voting on the target proposal, and the voting result constructed by the designated node further includes: a transaction vote generated based on the target additional data, the transaction vote indicating that the designated node agrees with the identified specific transaction; The consensus unit is also used to collect the first voting results constructed by each node, and to determine the consensus result of the N transactions based on the collected first voting results.

17. A computer device, comprising an input interface and an output interface, characterized in that, Also includes: Processor and computer storage media; The processor is adapted to implement one or more instructions, the computer storage medium stores one or more instructions, and the one or more instructions are adapted to be loaded by the processor and executed as described in any one of claims 1-15, which is a consensus processing method based on a blockchain network.

18. A computer storage medium, characterized in that, The computer storage medium stores one or more instructions, which are adapted to be loaded by a processor and executed as described in any one of claims 1-15, representing a consensus processing method based on a blockchain network.

19. A computer program product, characterized in that, The computer program product includes one or more instructions; when one or more instructions in the computer program are executed by the processor, they implement the consensus processing method based on a blockchain network as described in any one of claims 1-15.

Images