Block chain consensus method and related device

Abstract

The invention relates to the technical field of block chains, in particular to a block chain consensus method and a related device.The method comprises the steps that any consensus node executes multiple rounds of main selection voting for first other consensus nodes, and the following operations are executed in each round; receiving a first identifier set which is sent by the first other consensus node and contains N to-be-verified transaction identifiers; then, based on the transaction level of each candidate transaction identifier, obtaining N target transaction identifiers to form a second identifier set, and then, at least based on the difference between the first identifier set and the second identifier set, obtaining the accumulated number of votes of the first other consensus nodes, and respectively receiving the accumulated number of votes sent by each second other consensus node; and finally, obtaining a comprehensive vote number based on each accumulated vote number, and determining the first other consensus node as a main node when the comprehensive vote number meets a main node selection condition, thereby ensuring that the selected main node can adopt a fair mode to carry out priority ranking on transactions.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain consensus method and related devices. Background Art

[0002] Blockchain is a decentralized distributed database with chain storage and cannot be tampered with. The blockchain network is usually composed of multiple nodes, which jointly maintain the distributed database through a consensus mechanism. Therefore, multiple nodes are also called consensus nodes.

[0003] Under existing technology, during the blockchain transaction consensus process, a master node among multiple consensus nodes typically selects multiple target transactions from all received transaction requests and executes the corresponding transaction information to obtain the corresponding master node execution results. The obtained multiple target transactions are prioritized, and then the transaction information and master node execution results corresponding to the sorted multiple target transactions are packaged into blocks and broadcast to each slave node among the multiple consensus nodes for consensus. During the broadcast process, transaction information can be transmitted between any two slave nodes. After receiving the block sent by the master node, each slave node executes each target transaction in order of priority in the block and obtains the corresponding slave node execution results. The slave node execution results are then compared with the master node execution results to obtain the consensus verification results for the corresponding target transactions. For each transaction, when the master node execution result corresponding to the transaction information passes the consensus verification of each slave node, the transaction is completed.

[0004] However, the above method has the following problems:

[0005] 1. During the transaction information dissemination process, each slave node may selectively disseminate transaction information based on its own interests, or fail to conduct consensus verification on each target transaction according to the priority order in the block, affecting the fairness of blockchain transaction execution.

[0006] 2. The master node may abuse its right to package transactions, fail to prioritize target transactions according to the set rules, or ignore certain transactions, causing some transactions to fail to execute or fail to execute on time, affecting the efficiency of blockchain transaction execution.

[0007] In view of this, a new blockchain consensus method needs to be proposed to overcome the above defects. Summary of the Invention

[0008] This application provides a blockchain consensus method and related devices to improve the stability of smart following devices during actual use.

[0009] In a first aspect, an embodiment of the present application provides a blockchain consensus method, which is applied to any consensus node in a blockchain network, wherein any consensus node performs multiple rounds of leader election voting for a first other consensus node, wherein the following operations are performed in each round:

[0010] Receiving a first identifier set including N transaction identifiers to be verified sent by a first other consensus node;

[0011] Based on a transaction level associated with each of the at least one candidate transaction identifier, obtaining N target transaction identifiers to form a second identifier set; each candidate transaction identifier is obtained from a transaction request received from the blockchain network;

[0012] Obtaining, based at least on a difference between the first set of identifiers and the second set of identifiers and in combination with the historical votes of the first other consensus node, a cumulative number of votes of the first other consensus node in the current round, and receiving the cumulative number of votes of the first other consensus node sent by at least one second other consensus node;

[0013] The comprehensive votes of the first other consensus node in this round are obtained based on the accumulated votes, and when the comprehensive votes meet the preset master election conditions, the first other consensus node is determined as the master node in the blockchain network.

[0014] In a second aspect, an embodiment of the present application further provides a blockchain consensus device, which is applied to any consensus node in a blockchain network. Any consensus node performs multiple rounds of leader election voting for a first other consensus node, wherein the corresponding operations of each module in each round are as follows:

[0015] A data receiving module, configured to receive a first identifier set including N transaction identifiers to be verified, sent by a first other consensus node;

[0016] an identifier acquisition module, configured to acquire N target transaction identifiers to form a second identifier set based on a transaction level associated with each of the at least one candidate transaction identifier; each candidate transaction identifier is obtained from a transaction request received from the blockchain network;

[0017] a voting update module, configured to obtain the cumulative number of votes of the first other consensus node in the current round based on at least a difference between the first set of identifiers and the second set of identifiers, combined with the historical number of votes of the first other consensus node, and to receive the cumulative number of votes of the first other consensus node sent by at least one second other consensus node;

[0018] The master node determination module is used to obtain the comprehensive votes of the first other consensus node in this round based on the accumulated votes, and determine the first other consensus node as the master node in the blockchain network when the comprehensive votes meet the preset master election conditions.

[0019] Optionally, based on at least the difference between the first identifier set and the second identifier set and in combination with the historical votes of the first other consensus node, the cumulative votes of the first other consensus node in the current round are obtained, and the voting update module is further configured to:

[0020] Performing an identifier comparison on the first identifier set and the second identifier set to obtain a number of difference identifiers, where the difference identifiers include: transaction identifiers that appear in the first identifier set but not in the second identifier set, and transaction identifiers that appear in the second identifier set but not in the first identifier set;

[0021] Based at least on the number of identifiers, the historical votes of the first other consensus node are updated to obtain the cumulative votes of the first other consensus node in this round.

[0022] Optionally, based at least on the number of identifiers, the historical vote count of the first other consensus node is updated, and the voting update module is further configured to perform any one of the following operations:

[0023] Based on the number of identifiers, the historical vote count of the first other consensus node is updated;

[0024] Based on the number of identifiers and the priority difference, the historical vote count of the first other consensus node is updated; wherein the priority difference is obtained based on the execution priority of the N pending transaction identifiers in the first other consensus node and the execution priority in any consensus node;

[0025] Based on the number of identifiers, the priority difference and the execution sequence number, the historical votes of the first other consensus node are updated; wherein the execution sequence number is obtained based on some difference identifiers that appear in the second identifier set but do not appear in the first identifier set, combined with the transaction execution order corresponding to at least one candidate transaction identifier; the transaction execution order is obtained based on the transaction level associated with each of the at least one candidate transaction identifier.

[0026] Optionally, based on the number of identifiers, the historical vote count of the first other consensus node is updated. The voting update module is further used to:

[0027] When the number of identifiers is greater than a preset threshold, the first preset number of votes is subtracted from the historical number of votes of the first consensus node.

[0028] Optionally, based on the number of identifiers and the priority difference, the historical vote count of the first other consensus node is updated. The voting update module is further used to:

[0029] When the number of identifiers is not greater than a preset number threshold, and the priority difference is greater than a preset difference threshold, the second preset number of votes is subtracted from the historical number of votes of the first consensus node.

[0030] Optionally, based on the number of identifiers, priority difference, and execution sequence number, the historical vote count of the first other consensus node is updated. The voting update module is further used to:

[0031] When the number of identifiers is not greater than the preset number threshold, the priority difference is not greater than the preset difference threshold, and the execution sequence number is less than the preset sequence number threshold, the historical votes of the first consensus node are subtracted from the third preset votes.

[0032] Optionally, based on the number of identifiers, priority difference, and execution sequence number, the historical vote count of the first other consensus node is updated. The voting update module is further used to:

[0033] When the number of identifications is not greater than the preset number threshold, the priority difference is not greater than the preset difference threshold, and the execution sequence number is not less than the preset sequence number threshold, a corresponding comprehensive evaluation value is obtained based on the number of identifications, the priority difference, and the execution sequence number;

[0034] When the comprehensive evaluation value is greater than the preset evaluation threshold, a fourth preset number of votes is added to the historical number of votes of the first consensus node.

[0035] Optionally, the at least one candidate transaction identifier includes: at least one request transaction identifier respectively sent by each transaction partner, and the data receiving module is further configured to:

[0036] Sending a request transaction identifier to the first other consensus node and at least one second other consensus node respectively;

[0037] Receiving first timestamps returned by the first other consensus node and at least one second other consensus node, respectively; the first timestamps represent the time when the corresponding other consensus node placed the request transaction identifier into the first transaction pool;

[0038] A first average timestamp is obtained based on each received first timestamp, and a transaction level associated with a request transaction identifier is obtained based on the average timestamp and in combination with a transaction object level and a contract level corresponding to a request transaction identifier; the transaction object level and the contract level are stored on the blockchain when the corresponding transaction object is registered.

[0039] Optionally, the at least one candidate transaction identifier further includes: at least one shared transaction identifier respectively sent by the first other consensus node and the at least one second other consensus node, and the data receiving module is further configured to:

[0040] Receiving a shared transaction identifier sent by any other consensus node among the first other consensus node and the at least one second other consensus node;

[0041] Sending a second timestamp corresponding to the time when a shared transaction identifier is placed into the second transaction pool to any other consensus node, so that any other consensus node obtains a second average timestamp based on the second timestamp and third timestamps sent by all other nodes in the blockchain network except the any other consensus node, and saves the second average timestamp on the blockchain;

[0042] A second average timestamp is obtained from the blockchain, and based on the second average timestamp, a transaction object level and a contract level corresponding to a shared transaction identifier are combined to obtain a transaction level associated with the shared transaction identifier.

[0043] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in any one of the first aspects when executing the computer program.

[0044] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any method described in the first aspect.

[0045] In a fifth aspect, an embodiment of the present application provides a computer program product, which, when called by a computer, enables the computer to execute the method described in the first aspect.

[0046] The beneficial effects of this application are as follows:

[0047] The present application provides a blockchain consensus method and related devices, which relate to the field of blockchain technology and are applied to any consensus node in a blockchain network.

[0048] In an embodiment of the present application, any consensus node performs multiple rounds of leader election voting for the first other consensus node, wherein the following operations are performed in each round: first, a first identifier set containing N transaction identifiers to be verified, sent by the first other consensus node, is received; then, based on the transaction level associated with each of the at least one candidate transaction identifiers, a transaction execution order corresponding to the at least one candidate transaction identifier is obtained, and based on the transaction execution order, N target transaction identifiers are obtained from the at least one candidate transaction identifier to form a second identifier set. In this way, the transaction execution order is determined by the transaction level, ensuring the rapid and fair propagation and processing of transactions, while reducing the possibility of malicious nodes manipulating the transaction order, thereby improving the transparency and security of the system.

[0049] Then, based on at least the difference between the first identification set and the second identification set, combined with the historical votes of the first other consensus node, the cumulative votes of the first other consensus node in this round are obtained, and the cumulative votes of the first other consensus node sent by at least one second other consensus node are received respectively.

[0050] Finally, based on the cumulative votes, the comprehensive votes of the first other consensus node in this round are obtained. When the comprehensive votes meet the preset master election conditions, the first other consensus node is determined as the master node in the blockchain network. In this way, any consensus node obtains the comprehensive votes by combining itself and the cumulative votes given to the first other consensus node by each second other consensus node, and selects the master node based on the comprehensive votes, ensuring that the selected master node can prioritize transactions in a fair manner.

[0051] In summary, the solution provided by the embodiments of the present application effectively prevents malicious behavior of the master node, such as deliberately omitting high-priority transactions or irrationally adjusting the transaction order, thereby enhancing the robustness and trust of the blockchain system and improving the efficiency of blockchain transaction execution; at the same time, the transaction execution order is determined by the transaction level, thereby ensuring the fairness of blockchain transaction execution. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1A This is a schematic diagram of the blockchain data sharing system;

[0053] Figure 1B This is a schematic diagram of the block structure;

[0054] Figure 1C Schematic diagram of the block generation process;

[0055] Figure 2 This is a schematic diagram of an application scenario in an embodiment of the present application;

[0056] Figure 3 This is a logical diagram of a transaction identification broadcasting method in an embodiment of the present application;

[0057] Figure 4A This is a flowchart of a method for obtaining a transaction level associated with a request transaction identifier in an embodiment of the present application;

[0058] Figure 4B This is a logic diagram of a method for obtaining a transaction level associated with a request transaction identifier in an embodiment of the present application;

[0059] Figure 5A This is a flowchart of a method for obtaining a transaction level associated with a shared transaction identifier in an embodiment of the present application;

[0060] Figure 5B This is a logical diagram of a method for obtaining a transaction level associated with a shared transaction identifier in an embodiment of the present application;

[0061] Figure 6A This is a flowchart of a blockchain consensus method in an embodiment of the present application;

[0062] Figure 6B This is a logical diagram of a blockchain consensus method in an embodiment of the present application;

[0063] Figure 7 This is a schematic diagram of the internal module structure of a consensus node in an embodiment of the present application;

[0064] Figure 8 This is a flowchart of a method for obtaining cumulative votes in an embodiment of the present application;

[0065] Figure 9 This is a logic diagram of a voting update method in an embodiment of the present application;

[0066] Figure 10A This is a first schematic diagram of the overall process of block consensus verification and node rewards and penalties in an embodiment of the present application;

[0067] Figure 10B This is a second schematic diagram of the overall process of block consensus verification and node rewards and penalties in an embodiment of the present application;

[0068] Figure 11 This is a structural diagram of a blockchain consensus device in an embodiment of the present application;

[0069] Figure 12 This is a structural diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0070] In order to make the purpose, technical solutions and beneficial effects of this application more clear and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0071] The terms "first," "second," and the like in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate, such that the embodiments of the invention described herein can be practiced in sequences other than those illustrated or described herein.

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

[0073] The following explains some of the terms used in the embodiments of the present application to facilitate understanding by those skilled in the art.

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

[0075] (2) Smart contract: A computer protocol designed to communicate, verify or execute contracts in an information-based manner. Smart contracts allow trusted transactions to be conducted without a third party, and these transactions are traceable and irreversible.

[0076] (3) Transaction pool: A data structure in the blockchain network that stores pending transactions that have not yet been packaged into blocks. When a user submits a new transaction to the blockchain network, the transaction first enters the transaction pool. When the blockchain node is preparing to generate a new block, it selects a certain number of transactions from the transaction pool for packaging. The transaction pool helps improve the processing capacity of the blockchain network. It can also be used as a strategy to allow digital resource acquirers to prioritize transactions with higher fees for packaging, thereby increasing their profits.

[0077] (4) Gossip protocol: Also known as a rumor protocol or a propagation protocol, it is a communication protocol used to synchronize information between nodes in a distributed system. Its working principle is similar to the rumor propagation in social networks, that is, each node periodically exchanges information with several other randomly selected nodes. The advantage of this protocol is that it can quickly and efficiently propagate information in the network without a central coordinator, and it can maintain good robustness even when nodes are unstable or the network topology changes frequently. In blockchain, the Gossip protocol is often used to propagate transactions and blocks to ensure that all nodes can obtain the latest chain status.

[0078] (5) Transaction priority queue: A data structure in the blockchain transaction pool that is used to store and manage pending transactions according to their priority order. This queue is usually organized based on a priority algorithm. For example, the priority of a transaction can be determined based on factors such as transaction fees, transaction timestamps, and user reputation. When a blockchain node is ready to package a new block, it selects the highest priority transaction from the transaction priority queue to package it. This ensures that important or high-value transactions can be processed faster.

[0079] (6) Master election voting table: A data structure used in blockchain to elect a master node (or leader node) during the consensus process. In some consensus algorithms, such as Proof of Stake (PoS) or Delegated Proof of Stake (DPoS), nodes need to select one or more nodes to be responsible for creating new blocks according to certain rules. The master election voting table records the number of votes or weights of each node, which can be based on factors such as the node's holdings, historical performance, and network contribution. The higher the number of votes or weight of a node, the greater the probability of it being elected as the master node. This table is usually updated dynamically to reflect the latest status and behavior of the node.

[0080] The following is a brief introduction to the design concept of the embodiments of this application.

[0081] Under existing technology, during the blockchain transaction consensus process, due to the lack of enforceable transaction packaging rules or verification mechanisms, master nodes may abuse their power to package transactions. For example, they may unfairly adjust the transaction order or ignore certain transactions, causing some transactions to be unable to execute or fail to execute on time, affecting the efficiency of blockchain transaction execution. Such behavior may also undermine the security of the system, making the blockchain network vulnerable to malicious attacks or manipulation, and reducing the overall system's resistance to tampering. In addition, during the transaction information propagation process, each slave node may selectively propagate transaction information based on its own interests, or fail to conduct consensus verification on each target transaction according to the priority order within the block, affecting the fairness of blockchain transaction execution.

[0082] In view of this, the embodiments of the present application provide a blockchain consensus method and related devices, which relate to the field of blockchain technology and are applied to any consensus node in a blockchain network, that is, any slave node.

[0083] In an embodiment of the present application, after receiving the first identification set corresponding to N transaction identifications to be verified sent by the pending master node, the pending slave node selects N target transaction identifications from the multiple candidate transaction identifications stored by itself to form a second identification set, and updates the historical votes of the pending master node based on the difference between the first identification set and the second identification set to obtain the cumulative votes; at the same time, the pending slave node also receives the cumulative votes of the pending master node sent by other pending slave nodes, and then obtains a comprehensive vote based on the multiple cumulative votes obtained, and uses the comprehensive vote as the basis for whether to use the pending master node as the final master node.

[0084] This blockchain consensus method effectively prevents malicious behavior of master nodes, such as deliberately omitting high-priority transactions or irrationally adjusting the transaction order, thereby enhancing the robustness and trust of the blockchain system and improving the efficiency of blockchain transaction execution. At the same time, the transaction execution order is determined by transaction level, ensuring the fairness of blockchain transaction execution.

[0085] After introducing the design concept of this application, the blockchain technology used in the embodiments of this application is introduced in detail below.

[0086] See also Figure 1A The data sharing system shown, the data sharing system 100 refers to a system for sharing data between nodes, and the data sharing system may include multiple nodes 101, and the multiple nodes 101 may refer to each client in the data sharing system. Each node 101 can receive input information during normal operation and maintain the shared data in the data sharing system based on the received input information. In order to ensure the intercommunication of information in the data sharing system, an information connection can exist between each node in the data sharing system, and information can be transmitted between nodes through the above-mentioned information connection. For example, when any node in the data sharing system receives input information, the other nodes in the data sharing system obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

[0087] Each node in the data sharing system has a corresponding node identifier, and each node in the data sharing system can store the node identifiers of other nodes in the data sharing system so that the generated blocks can be broadcast to other nodes in the data sharing system based on the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the table below, and store the node name and node identifier in the node identifier list accordingly. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node. Only the IP address is used as an example for explanation.

[0088] Table 1

[0089] Node Name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N xxx.xxx.xxx.xxx

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

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

[0092] SHA 256(SHA 256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

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

[0094] In this way, when a random number that satisfies the above formula is calculated, the information can be stored accordingly, and the block header and block body can be generated to obtain the current block. Subsequently, the blockchain node sends the newly generated block to other nodes in the data sharing system based on the node identifiers of other nodes in the data sharing system. The other nodes verify the newly generated block and, after verification, add the newly generated block to their stored blockchain.

[0095] The following describes the blockchain consensus method provided by the exemplary embodiment of the present application in conjunction with the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present application, and the implementation of the present application is not limited in this respect.

[0096] See Figure 2 As shown, it is a schematic diagram of an application scenario in an embodiment of the present application. The application scenario includes: terminal devices 1101, 1102, 1103, and 1104, and a blockchain network 120 composed of consensus nodes 1201, 1202, 1203, and 1204. It can be understood that the terminal devices 1101, 1102, 1103, and 1104 are connected to the blockchain network 120 through network communication, respectively, and the nodes included in the blockchain network 120 are also interconnected through the communication network. The network can include various connection types, such as wireless communication links, wired and fiber optic cables, etc.

[0097] Among them, each transaction party can send a transaction request to the blockchain network through terminal devices 1101, 1102, 1103, and 1104 respectively. The terminals include but are not limited to mobile phones, tablets, laptops, desktop computers and other devices. The terminal can be installed with an interview management client, which can be an online platform, application, web page, mini program, etc.

[0098] The consensus nodes 1201, 1202, 1203, and 1204 in the blockchain network 120 are servers. After receiving a transaction request sent by a transaction object, each node obtains a transaction identifier from the transaction request and broadcasts the transaction identifier to all other consensus nodes. Each consensus node is preset with a pending master node. The pending master node packages multiple transaction identifiers to be verified into blocks and sends the blocks to other consensus nodes. Each other consensus node votes for the pending master node respectively.

[0099] The following describes a blockchain consensus method provided by an exemplary embodiment of the present application in conjunction with the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present application, and the implementation of the present application is not limited in this respect.

[0100] In the embodiment of the present application, before the blockchain network reaches consensus, any consensus node that receives a transaction request needs to broadcast the request transaction identifier to other nodes, and receive the shared transaction identifiers sent by each other consensus node, and use each request transaction identifier and each shared transaction identifier as candidate transaction identifiers. Figure 3 As shown, it is a schematic diagram of the transaction broadcast result in an embodiment of the present application. After consensus node 1 receives transaction tx1 sent by the transaction object through the client, it broadcasts transaction tx1 to consensus node 2, consensus node 3, and consensus node 4; consensus node 3 receives transaction tx2 sent by the transaction object through the client, and broadcasts transaction tx2 to consensus node 1, consensus node 2, and consensus node 4.

[0101] Specifically, after the transaction object sends a transaction request with a certificate and signature to any consensus node on the blockchain, the consensus node calls the authentication module to verify the certificate and signature. When the certificate or signature verification fails, the authentication module returns the verification result; when both the certificate verification and the signature verification pass, the consensus node broadcasts the request transaction identifier in the transaction request and the transaction source node to other consensus nodes through the gossip protocol, and calculates the transaction level of the request transaction identifier based on the receipts of other consensus nodes. Figure 4A As shown, it is a flowchart of a method for obtaining a transaction level associated with a request transaction identifier in an embodiment of the present application. Figure 4A , and explain the specific steps in detail:

[0102] Step 41: Send a request transaction identifier to the first other consensus node and at least one second other consensus node respectively.

[0103] Step 42: Receive first timestamps returned by the first other consensus node and at least one second other consensus node respectively.

[0104] The first timestamp represents the time when the corresponding other consensus nodes put the requested transaction identifier into the first transaction pool.

[0105] For example, see Figure 3 As shown in the figure, after consensus node 1 sends the transaction identifier tx1 to consensus node 2, consensus node 3 and consensus node 4, consensus node 2, consensus node 3 and consensus node 4 respectively put the transaction identifier tx1 into the transaction pool and return the timestamp corresponding to the time when the transaction identifier tx1 was put into the transaction pool to consensus node 1, such as 10:00, 10:10, and 10:20.

[0106] Step 43: Obtain a first average timestamp based on the received first timestamps, and obtain a transaction level associated with a request transaction identifier based on the average timestamp and in combination with the transaction object level and contract level corresponding to the request transaction identifier.

[0107] The transaction object level and contract level are stored on the blockchain when the corresponding transaction object is registered.

[0108] In an embodiment of the present application, after sending a request transaction identifier to each other consensus node, the consensus node determines whether more than half of the receipts are received within a preset time period. If not, it feedbacks information about the transaction identifier broadcast abnormality; if so, it continues to calculate the first average timestamp based on the received first timestamps.

[0109] For example, see Figure 4B As shown, after consensus node 1 sends transaction identifier tx1 to consensus nodes 2, 3, ..., M, it calculates a first average timestamp of 10:10 based on the received timestamps 10:00, 10:10, and 10:20 (assuming M = 3). When a transaction object is registered on the blockchain, the registration node saves the transaction object identifier and the contract level corresponding to the smart contract that executes the requested transaction sent by the transaction object in the blockchain's state database, synchronizing transaction object-related information between consensus nodes on the blockchain. The consensus node combines the transaction object level, contract level, and first average timestamp to obtain the transaction level associated with the transaction identifier. The higher the transaction object level and contract level, and the smaller the first average timestamp, the higher the transaction level. The consensus node can obtain the transaction object level and contract level corresponding to the transaction identifier tx1 from the blockchain and combine them with the first average timestamp to obtain the corresponding transaction level.

[0110] In this way, in the process of determining the transaction level corresponding to the requested transaction identifier, the timestamp information provided by each other consensus node is comprehensively considered, and the transaction object level and contract level are combined. By referring to multiple factors, the fairness and accuracy of the transaction level calculation are guaranteed.

[0111] Furthermore, the pending master node also receives the shared transaction identifier sent by other consensus nodes, see Figure 5A As shown, it is a flow chart of a method for obtaining a transaction level corresponding to a shared transaction identifier in an embodiment of the present application. Figure 5A , and explain the specific steps in detail:

[0112] Step 51: Receive a shared transaction identifier sent by the first other consensus node and any other consensus node among at least one second other consensus node.

[0113] For example, see Figure 5B As shown, consensus node 1 (pending master node) receives the shared transaction identifier tx2 sent by consensus node 2 (other consensus node). At the same time, consensus node 2 also sends the shared transaction identifier tx2 to consensus node 3, consensus node 4...consensus node M.

[0114] Step 52: Send a second timestamp corresponding to the time when a shared transaction identifier is placed into the second transaction pool to any other consensus node, so that any other consensus node obtains a second average timestamp based on the second timestamp and the third timestamps sent by all other nodes in the blockchain network except any other consensus node, and saves the second average timestamp on the blockchain.

[0115] For example, see Figure 5B As shown, consensus node 1 sends a second timestamp to consensus node 2, and consensus node 3, consensus node 4...consensus node M also sends a third timestamp to consensus node 2. Then, consensus node 2 can calculate a second average timestamp based on the second timestamp and each third timestamp.

[0116] It should be noted that the method for consensus node 2 to calculate the second average timestamp is the same as the method for the aforementioned consensus node to calculate the first average timestamp, and will not be repeated here.

[0117] Step 53: Obtain a second average timestamp from the blockchain, and based on the second average timestamp, combine the transaction object level and contract level corresponding to a shared transaction identifier to obtain a transaction level associated with the shared transaction identifier.

[0118] In this way, in the process of determining the transaction level corresponding to the shared transaction identifier, the timestamp information provided by each other consensus node is comprehensively considered, and the transaction object level and contract level are combined. By referring to multiple factors, the fairness and accuracy of the transaction level calculation are guaranteed.

[0119] In the embodiment of the present application, the method by which consensus node 1 calculates the transaction level corresponding to the shared transaction identifier tx2 is the same as the method by which consensus node 1 calculates the transaction level corresponding to the requested transaction identifier tx1, and will not be repeated here.

[0120] The above is a pre-step of a blockchain consensus method in an embodiment of the present application. After each consensus node in the blockchain shares a transaction identifier and obtains multiple candidate transaction identifiers, the consensus node can determine the master node in the blockchain network through blockchain transaction consensus.

[0121] Specifically, a blockchain consensus method provided in an embodiment of the present application can be applied to any consensus node in a blockchain network, and any consensus node performs multiple rounds of leader election voting for the first other consensus nodes, wherein, in each round, Figure 6A Steps shown:

[0122] Step 61: Receive a first identifier set including N transaction identifiers to be verified sent by a first other consensus node.

[0123] For example, see Figure 6B As shown, assuming N=6, consensus node 1 receives the first identifier set {tx1, tx2, tx3, tx4, tx5, tx6} sent by consensus node 2 (to be determined as the master node). Specifically, the first identifier set in consensus node 2 is obtained using the following method:

[0124] See Figure 7 As shown, after receiving the block signal sent by the monitoring module, the consensus node 2 mobilizes the block generation module to send a transaction acquisition request to the transaction priority queue of the transaction pool module. Among them, the influencing factors of the execution priority corresponding to each transaction identifier in the transaction priority queue are the same as the influencing factors of the above-mentioned transaction level, and are all determined based on the transaction object level, contract level, and average timestamp corresponding to the transaction identifier.

[0125] Furthermore, after receiving the transaction acquisition request, the transaction pool module first determines whether the number of transactions in the transaction priority queue is greater than the block transaction number threshold. If so, the head transaction identifier in the transaction priority queue that meets the transaction number threshold is returned to the block generator. If not, all transaction identifiers in the transaction priority queue are returned to the block generator; then, the block generator packages the transaction information corresponding to all received transaction identifiers into a new block, and uses the virtual machine engine to schedule ordinary user contracts, execute transactions according to each transaction information, and record the transaction execution results in the new block; at the same time, the block generator executes the block packaging and screening system contract, and encapsulates all received transaction identifiers (i.e., N transaction identifiers to be verified) into a new block. Finally, consensus node 2 sends the new block to all other consensus nodes (consensus node 1 and consensus node 3) for consensus verification.

[0126] Step 62: Based on the transaction level associated with at least one candidate transaction identifier, N target transaction identifiers are obtained to form a second identifier set.

[0127] Each candidate transaction identifier is obtained from a transaction request received from the blockchain network.

[0128] In an embodiment of the present application, the consensus node sorts the candidate transaction identifiers in descending order of transaction level, and selects the top N target transaction identifiers to form a second identifier set. The number of identifiers in the second identifier set remains consistent with that in the first identifier set.

[0129] For example, see Figure 6BAs shown in the figure, consensus node 1 arranges the 10 candidate transaction identifiers in descending order of transaction level as {tx1, tx2, tx3, tx4, tx5, tx7, tx6, tx8, tx9, tx10}, and selects the top 6 target transaction identifiers to form the second identifier set {tx1, tx2, tx3, tx4, tx5, tx7}.

[0130] Step 63: Based on at least the difference between the first set of identifiers and the second set of identifiers, combined with the historical votes of the first other consensus node, obtain the cumulative votes of the first other consensus node in this round, and receive the cumulative votes of the first other consensus node sent by at least one second other consensus node.

[0131] It is worth noting that if the current round is the first round, the historical vote count is the preset initial vote count, and the initial vote count of each consensus node in the blockchain network is the same.

[0132] For details, see Figure 8 As shown, when obtaining the cumulative votes of the first other consensus node, the consensus node specifically performs the following steps:

[0133] Step 631: perform a comparison between the first identification set and the second identification set to obtain the number of different identifications.

[0134] The difference identifiers include: transaction identifiers that appear in the first identifier set but not in the second identifier set, and transaction identifiers that appear in the second identifier set but not in the first identifier set.

[0135] For example, for the above-mentioned first identifier set {tx1, tx2, tx3, tx4, tx5, tx6} and the second identifier set {tx1, tx2, tx3, tx4, tx5, tx7}, the difference identifier that appears in the first identifier set but not in the second identifier set is tx6, and the difference transaction identifier that appears in the second identifier set but not in the first identifier set is tx7. Therefore, the number of difference identifiers is 2.

[0136] Step 632: Based at least on the number of identifiers, update the historical votes of the first other consensus node to obtain the cumulative votes of the first other consensus node.

[0137] Specifically, when executing step 632, the consensus node performs any one of the following operations:

[0138] Operation 1: Based on the number of identifiers, update the historical vote count of the first other consensus node.

[0139] Specifically, when the number of identifiers is greater than a preset number threshold, the first preset number of votes (eg, minus 1) is subtracted from the historical number of votes of the first consensus node.

[0140] For example, assuming that the preset number threshold is 1, the historical number of votes of consensus node 2 is 90, and the number of difference identifiers obtained by consensus node 1 in step 631 is 2, which is greater than the preset number threshold, then the historical number of votes is reduced by 1, and the cumulative number of votes of consensus node 2 is 89.

[0141] In this way, updating the historical votes of the pending master node according to the number of identifications of the difference identification can effectively avoid the malicious behavior of the master node omitting high-priority nodes, thereby ensuring the fairness of blockchain transactions.

[0142] Operation 2: Update the historical vote count of the first other consensus node based on the number of identifiers and the priority difference;

[0143] The priority difference is obtained based on the execution priority of the N pending transaction identifiers in the first other consensus node and the execution priority in any consensus node;

[0144] In an embodiment of the present application, when the consensus node utilizes a virtual machine engine to execute a block packaging and screening system contract and encapsulates N pending transaction identifiers into a new block, it also encapsulates the N pending transaction identifiers into an array of execution priorities in the first other consensus node (consensus node 2) into the new block.

[0145] Specifically, when the number of identifiers is not greater than the preset number threshold, and the priority difference is greater than the preset difference threshold, the historical votes of the first consensus node are subtracted from the second preset number of votes (e.g., minus 1).

[0146] For example, see Figure 9 As shown, consensus node 2 (pending master node) organizes the execution priorities corresponding to the six pending transaction identifiers tx1-tx6 into an array:

[0147] [tx1(987),tx2(976),tx3(964),tx4(963),tx5(932),tx6(912)], and encapsulate the array into a new block and send it to consensus node 1. Consensus node 1 calculates the priority differences through the virtual machine engine as tx1(-7),tx2(+2),tx3(+3),tx4(+2),tx5(+4),tx6(-4), and the maximum priority difference is 7. Assuming the preset quantity threshold is 3, the identification quantity 2 is less than the quantity threshold. At this time, the cumulative number of votes is determined based on the priority difference.

[0148] Optionally, the maximum priority value difference is compared with a preset difference threshold. For example, assuming that the preset difference threshold is 5, the maximum priority value difference is greater than the difference threshold, and the historical votes of consensus node 2, 90, are subtracted by 1 to obtain a cumulative vote of 89.

[0149] In this way, the historical votes of the pending master node are updated according to the number of identifiers and the priority difference, which can effectively prevent the master node from arbitrarily tampering with the transaction execution order and thus ensure the fairness of blockchain transactions.

[0150] Operation 3: Update the historical vote count of the first other consensus node based on the number of identifiers, priority difference, and execution sequence number;

[0151] Among them, the execution sequence number is obtained based on some difference identifiers that appear in the second identifier set but do not appear in the first identifier set, combined with the transaction execution order corresponding to at least one candidate transaction identifier; the transaction execution order is obtained based on the transaction level associated with each of the at least one candidate transaction identifier.

[0152] Specifically, when the number of identifiers is not greater than a preset number threshold, the priority difference is not greater than a preset difference threshold, and the execution sequence number is less than a preset sequence number threshold, the historical number of votes of the first consensus node is subtracted by a third preset number of votes (e.g., minus 1).

[0153] When the number of identifiers is not greater than the preset number threshold, the priority difference is not greater than the preset difference threshold, and the execution sequence number is not less than the preset sequence number threshold, a corresponding comprehensive evaluation value is obtained based on the number of identifiers, the priority difference, and the execution sequence number; when the comprehensive evaluation value is greater than the preset evaluation threshold, a fourth preset number of votes (e.g., plus 1) is added to the historical votes of the first consensus node.

[0154] For example, when the number of identifiers 2 is less than the preset number threshold 3, and the priority difference 7 is less than the preset difference threshold 10, the cumulative votes of consensus node 2 are obtained based on the execution sequence number. Specifically, the partial difference identifier that appears in the second identifier set but not in the first identifier set is tx7, and its execution sequence number in consensus node 1 is 6. Assuming the sequence number threshold is 7 and the execution sequence number is less than the sequence number threshold, the historical votes of consensus node 2, 90, are subtracted by 1, resulting in a cumulative vote of 89. Assuming the sequence number threshold is 3 and the execution sequence number is greater than the sequence number threshold, the comprehensive evaluation value is calculated as 85 based on the degree to which the number of identifiers deviates from the quantity threshold, the degree to which the priority difference deviates from the difference threshold, and the degree to which the execution sequence number deviates from the sequence number threshold. Assuming the evaluation threshold is 80, the historical votes of consensus node 2, 90, are increased by 1, resulting in a cumulative vote of 91.

[0155] In this way, the historical votes for the pending master node are updated based on the three factors of the number of identifiers, priority difference, and execution sequence number, forming a complete and scientific reward and punishment strategy and process, ensuring the fairness of the master node determination process, and thus ensuring the fairness of blockchain transactions.

[0156] Step 64: Based on the accumulated votes, the comprehensive vote count of the first other consensus node in this round is obtained, and when the comprehensive vote count meets the preset master election condition, the first other consensus node is determined as the master node in the blockchain network.

[0157] Optionally, in an embodiment of the present application, the preset master election condition is to select the consensus node with the highest comprehensive votes in the blockchain network as the master node.

[0158] For example, see Figure 6B As shown in the figure, assuming that the blockchain network contains three consensus nodes, the cumulative votes of consensus node 1 for consensus node 2 are 91, and the cumulative votes of consensus node 3 for consensus node 2 are 93, then the total number of votes is 184. Assuming that the total votes obtained by consensus nodes 1 and 3 are 180 and 175 respectively, consensus node 2 with the highest cumulative votes is selected as the master node.

[0159] Furthermore, the new block sent by the first other consensus node (pending master node) to the consensus node (pending slave node) contains ordinary user contract transactions and block packaging and screening system contract transactions. Therefore, after receiving the new block, the consensus node needs to perform consensus verification on the two transactions separately. Figure 10A and Figure 10B As shown, from the perspective of the pending slave node, the embodiment of the present application provides a schematic diagram of the overall process of block consensus verification and node rewards and penalties. Figure 10A and Figure 10B , and explain the specific steps in detail:

[0160] Step 1001: Receive a new block sent by the pending master node.

[0161] Step 1002: The scheduling module schedules the transaction for verification to determine whether the current transaction is an ordinary user contract transaction. If so, execute step 1003; otherwise, execute step 1005.

[0162] Step 1003: The scheduling module starts the ordinary user contract to execute the transaction and determines whether the transaction execution result is consistent with the one sent by the pending master node. If so, execute step 1014; otherwise, execute step 1004.

[0163] Step 1004: Return an error indicating that the verification results of the ordinary user contract transaction are inconsistent, and go to step 1021.

[0164] Step 1005: Execute the block packaging and screening system contract, and use the virtual machine engine to obtain N transaction identifiers to be verified and the corresponding transaction priorities in the new block.

[0165] Step 1006: Based on the transaction level associated with each of the at least one candidate transaction identifier, obtain a transaction execution order corresponding to the at least one candidate transaction identifier, and based on the transaction execution order, obtain N target transaction identifiers from the at least one candidate transaction identifier.

[0166] Step 1007: Obtain the number of different identifiers between the N transaction identifiers to be verified and the N target transaction identifiers.

[0167] Step 1008: Determine whether the number of difference identifiers is greater than the quantity threshold. If so, execute step 1009; otherwise, execute step 1010.

[0168] Step 1009: Return an error indicating that the number of difference identifiers is too large, and go to step 1016.

[0169] Step 1010: Determine whether the priority difference is greater than the difference threshold. If so, execute step 1011; otherwise, execute step 1012.

[0170] Step 1011: Return an error indicating that the priority difference is too large.

[0171] Step 1012: Determine whether the execution sequence number is less than the sequence number threshold. If so, execute step 1013; otherwise, execute step 1014.

[0172] Step 1013: Return an error indicating that the pending master node has not packaged the high-priority transaction.

[0173] Step 1014: Check whether all pending transactions in the new block have been verified. If so, proceed to step 1015; otherwise, proceed to step 1003.

[0174] Step 1015: Check whether the block packaging and screening system contract transaction verification in the new block passes. If so, execute step 1016; otherwise, execute step 1019.

[0175] Step 1016: Obtain a corresponding comprehensive evaluation value based on the number of identifiers, the priority difference, and the execution sequence number.

[0176] Step 1017: Determine whether the comprehensive evaluation value is greater than the evaluation threshold. If so, execute step 1018; otherwise, execute step 1020.

[0177] Step 1018: Add the preset number of votes (eg, plus 1) to the historical number of votes of the pending master node to obtain the cumulative number of votes.

[0178] Step 1019: Subtract the preset number of votes (eg, minus 1) from the historical number of votes of the pending master node to obtain the cumulative number of votes.

[0179] Step 1020: Store the new block on the blockchain and update the state database.

[0180] Step 1021: End.

[0181] Based on the above embodiments, in practical applications, the application scenarios involved in the technical solutions provided by this application mainly include the following aspects:

[0182] 1. Decentralized Finance (DeFi) Platforms: In DeFi applications, transaction fairness and transparency are crucial. This solution can be used to ensure that all transactions are broadcast and processed in a fair and transparent manner, thereby enhancing user trust in the platform. Adaptive transaction prioritization can help rationally arrange transaction order, for example, ensuring that critical financial transactions (such as debt repayments or collateral liquidations) are prioritized during periods of high network congestion.

[0183] 2. Supply Chain Management System: The authenticity and immutability of transaction records are core requirements in supply chain management. This solution's transaction pool contract and intelligent reward and penalty mechanism can ensure the accuracy and consistency of transaction records, thereby improving the transparency and efficiency of the entire supply chain. For example, it can ensure that records of goods delivery and payment are recorded and verified in the order in which they actually occurred.

[0184] 3. Voting and Governance System: In blockchain governance or electronic voting systems, the fair counting of every vote is crucial. This solution ensures the fair broadcast and processing of all voting transactions, preventing any node from maliciously manipulating voting results. Furthermore, the number of votes cast can be directly used to calculate voting weight and determine voting results.

[0185] 4. Gaming and social networking platforms: In blockchain gaming or social networking platforms, user-generated transactions (such as virtual item trading and social interactions) need to be processed quickly and fairly. This solution can provide a transparent and fair trading environment, enhance the user experience, and incentivize users to comply with platform rules through intelligent reward and punishment algorithms.

[0186] 5. Energy Trading Market: In distributed energy resource management and trading markets, ensuring the timeliness and accuracy of transactions is crucial to maintaining market stability. This solution can help achieve real-time synchronization and priority assessment of energy transactions, ensuring that critical transactions (such as emergency power purchases) are prioritized.

[0187] 6. Identity verification and data sharing platform: On identity verification and data sharing platforms that require high security and privacy protection, this solution can ensure that users' data transactions are carried out in accordance with established rules, while maintaining the security of the network and the integrity of nodes through intelligent reward and punishment algorithms.

[0188] These application scenarios demonstrate the broad applicability of this solution across various industries, particularly in sectors with high demands for transaction fairness, security, and transparency. Implementing this solution can improve the overall performance and user trust of blockchain networks, driving the commercial application and social acceptance of blockchain technology.

[0189] Furthermore, although the operations of the method of the present application are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0190] Based on the same technical concept, see Figure 11 As shown, the embodiment of the present application further provides a blockchain consensus device, which is applied to any consensus node in a blockchain network. Any consensus node performs multiple rounds of leader election voting for the first other consensus nodes, wherein the corresponding operations of each module in each round are as follows:

[0191] The data receiving module 1101 is configured to receive a first identifier set including N transaction identifiers to be verified, sent by a first other consensus node;

[0192] An identifier acquisition module 1102 is configured to acquire N target transaction identifiers to form a second identifier set based on a transaction level associated with each of the at least one candidate transaction identifiers; each candidate transaction identifier is obtained from a transaction request received from the blockchain network;

[0193] The voting update module 1103 is configured to obtain the cumulative votes of the first other consensus node in the current round based on at least the difference between the first identifier set and the second identifier set and the historical votes of the first other consensus node, and to receive the cumulative votes of the first other consensus node sent by at least one second other consensus node.

[0194] The master node determination module 1104 is used to obtain the comprehensive votes of the first other consensus node in this round based on the accumulated votes, and determine the first other consensus node as the master node in the blockchain network when the comprehensive votes meet the preset master election conditions.

[0195] Optionally, based on at least the difference between the first identifier set and the second identifier set and in combination with the historical votes of the first other consensus node, the cumulative votes of the first other consensus node in the current round are obtained, and the voting update module 1103 is further configured to:

[0196] Performing an identifier comparison on the first identifier set and the second identifier set to obtain a number of difference identifiers, where the difference identifiers include: transaction identifiers that appear in the first identifier set but not in the second identifier set, and transaction identifiers that appear in the second identifier set but not in the first identifier set;

[0197] Based at least on the number of identifiers, the historical votes of the first other consensus node are updated to obtain the cumulative votes of the first other consensus node in this round.

[0198] Optionally, based at least on the number of identifiers, the historical vote count of the first other consensus node is updated, and the voting update module 1103 is further configured to perform any one of the following operations:

[0199] Based on the number of identifiers, the historical vote count of the first other consensus node is updated;

[0200] Based on the number of identifiers and the priority difference, the historical vote count of the first other consensus node is updated; wherein the priority difference is obtained based on the execution priority of the N pending transaction identifiers in the first other consensus node and the execution priority in any consensus node;

[0201] Based on the number of identifiers, the priority difference and the execution sequence number, the historical votes of the first other consensus node are updated; wherein the execution sequence number is obtained based on some difference identifiers that appear in the second identifier set but do not appear in the first identifier set, combined with the transaction execution order corresponding to at least one candidate transaction identifier; the transaction execution order is obtained based on the transaction level associated with each of the at least one candidate transaction identifier.

[0202] Optionally, based on the number of identifiers, the historical vote count of the first other consensus node is updated, and the voting update module 1103 is further configured to:

[0203] When the number of identifiers is greater than a preset threshold, the first preset number of votes is subtracted from the historical number of votes of the first consensus node.

[0204] Optionally, based on the number of identifiers and the priority difference, the historical vote count of the first other consensus node is updated, and the voting update module 1103 is further configured to:

[0205] When the number of identifiers is not greater than a preset number threshold, and the priority difference is greater than a preset difference threshold, the second preset number of votes is subtracted from the historical number of votes of the first consensus node.

[0206] Optionally, based on the number of identifiers, the priority difference, and the execution sequence number, the historical vote count of the first other consensus node is updated, and the voting update module 1103 is further configured to:

[0207] When the number of identifiers is not greater than the preset number threshold, the priority difference is not greater than the preset difference threshold, and the execution sequence number is less than the preset sequence number threshold, the historical votes of the first consensus node are subtracted from the third preset votes.

[0208] Optionally, based on the number of identifiers, the priority difference, and the execution sequence number, the historical vote count of the first other consensus node is updated, and the voting update module 1103 is further configured to:

[0209] When the number of identifications is not greater than the preset number threshold, the priority difference is not greater than the preset difference threshold, and the execution sequence number is not less than the preset sequence number threshold, a corresponding comprehensive evaluation value is obtained based on the number of identifications, the priority difference, and the execution sequence number;

[0210] When the comprehensive evaluation value is greater than the preset evaluation threshold, a fourth preset number of votes is added to the historical number of votes of the first consensus node.

[0211] Optionally, the at least one candidate transaction identifier includes: at least one request transaction identifier respectively sent by each transaction partner, and the data receiving module 1101 is further configured to:

[0212] Sending a request transaction identifier to the first other consensus node and at least one second other consensus node respectively;

[0213] Receiving first timestamps returned by the first other consensus node and at least one second other consensus node, respectively; the first timestamps represent the time when the corresponding other consensus node placed the request transaction identifier into the first transaction pool;

[0214] A first average timestamp is obtained based on each received first timestamp, and a transaction level associated with a request transaction identifier is obtained based on the average timestamp and in combination with a transaction object level and a contract level corresponding to a request transaction identifier; the transaction object level and the contract level are stored on the blockchain when the corresponding transaction object is registered.

[0215] Optionally, the at least one candidate transaction identifier further includes: at least one shared transaction identifier respectively sent by the first other consensus node and the at least one second other consensus node, and the data receiving module 1101 is further configured to:

[0216] Receiving a shared transaction identifier sent by any other consensus node among the first other consensus node and the at least one second other consensus node;

[0217] Sending a second timestamp corresponding to the time when a shared transaction identifier is placed into the second transaction pool to any other consensus node, so that any other consensus node obtains a second average timestamp based on the second timestamp and third timestamps sent by all other nodes in the blockchain network except the any other consensus node, and saves the second average timestamp on the blockchain;

[0218] A second average timestamp is obtained from the blockchain, and based on the second average timestamp, a transaction object level and a contract level corresponding to a shared transaction identifier are combined to obtain a transaction level associated with the shared transaction identifier.

[0219] Based on the same technical concept, an embodiment of the present application also provides an electronic device that can implement the method flow of blockchain consensus provided in the above embodiments of the present application.

[0220] In one embodiment, the electronic device may be a server, or a terminal device or other electronic device.

[0221] See Figure 12 As shown, the electronic device may include:

[0222] At least one processor 1201, and a memory 1202 connected to the at least one processor 1201. The specific connection medium between the processor 1201 and the memory 1202 is not limited in the embodiment of the present application. Figure 12 In the example, the processor 1201 and the memory 1202 are connected via the bus 1200. Figure 12 The bus 1200 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 12 The diagram is represented by only one thick line, but this does not mean that there is only one bus or one type of bus. Alternatively, the processor 1201 may also be referred to as a controller, without limitation to the name.

[0223] In the embodiment of the present application, the memory 1202 stores instructions that can be executed by at least one processor 1201. At least one processor 1201 can execute a blockchain consensus method discussed above by executing the instructions stored in the memory 1202. The processor 1201 can implement Figure 11 The functions of each module in the device shown.

[0224] Among them, the processor 1201 is the control center of the device, which can use various interfaces and lines to connect the various parts of the entire control device, and monitor the device as a whole by running or executing instructions stored in the memory 1202 and calling data stored in the memory 1202, the various functions of the device and processing data.

[0225] In one possible design, processor 1201 may include one or more processing units. Processor 1201 may integrate an application processor and a modem processor. The application processor primarily processes the operating system, user interface, and application programs, while the modem processor primarily processes wireless communications. It is understood that the modem processor may not be integrated into processor 1201. In some embodiments, processor 1201 and memory 1202 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0226] Processor 1201 can be a general-purpose processor, such as a CPU, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of a blockchain consensus method disclosed in the embodiments of this application can be directly implemented as a hardware processor, or can be implemented using a combination of hardware and software modules in the processor.

[0227] Memory 1202 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. Memory 1202 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. Memory 1202 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 1202 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0228] By designing and programming the processor 1201, the code corresponding to the blockchain consensus method described in the above embodiment can be solidified into the chip, so that the chip can execute Figure 3 The steps of a blockchain consensus method in the embodiment shown are as follows: How to design and program the processor 1201 is a technique well known to those skilled in the art and will not be described in detail here.

[0229] Based on the same inventive concept, an embodiment of the present application also provides a storage medium, which stores computer instructions. When the computer instructions are executed on a computer, the computer executes a blockchain consensus method discussed above.

[0230] In some possible implementations, various aspects of a blockchain consensus method provided by the present application may also be implemented in the form of a program product, which includes program code. When the program product is run on an apparatus, the program code is used to cause the control device to execute the steps of a blockchain consensus method according to various exemplary embodiments of the present application described above in this specification.

[0231] It should be noted that although several units or subunits of the device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, depending on the embodiment of the application, the features and functions of two or more units described above can be embodied in a single unit. Conversely, the features and functions of a single unit described above can be further divided and embodied by multiple units.

[0232] Furthermore, although the operations of the method of the present application are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0233] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0234] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each flow and / or box in the flow chart and / or block diagram, as well as the combination of the flow chart and / or box in the flow chart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more flow charts and / or one or more boxes in the block diagram.

[0235] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0236] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0237] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A blockchain consensus method, characterized in that: Applied to any consensus node in a blockchain network, the consensus node performs multiple rounds of leader election voting on a first other consensus node, wherein the following operations are performed in each round: Receiving a first identifier set including N transaction identifiers to be verified, sent by the first other consensus node; Based on a transaction level associated with each of the at least one candidate transaction identifier, obtaining N target transaction identifiers to form a second identifier set; each of the candidate transaction identifiers is obtained from a transaction request received from the blockchain network; Obtaining, based at least on the difference between the first set of identifiers and the second set of identifiers and in combination with the historical votes of the first other consensus node, the cumulative votes of the first other consensus node in the current round, and receiving the cumulative votes of the first other consensus node from at least one second other consensus node respectively; Based on the accumulated votes, the comprehensive votes of the first other consensus node in this round are obtained, and when the comprehensive votes meet the preset master election conditions, the first other consensus node is determined as the master node in the blockchain network.

2. The method according to claim 1, wherein The obtaining, based at least on the difference between the first identifier set and the second identifier set and in combination with the historical votes of the first other consensus node, of the cumulative votes of the first other consensus node in the current round includes: performing an identifier comparison on the first identifier set and the second identifier set to obtain a number of difference identifiers, the difference identifiers including: transaction identifiers that appear in the first identifier set but not in the second identifier set, and transaction identifiers that appear in the second identifier set but not in the first identifier set; Based at least on the number of identifiers, the historical number of votes of the first other consensus node is updated to obtain the cumulative number of votes of the first other consensus node in the current round.

3. The method according to claim 2, wherein The updating of the historical vote count of the first other consensus node based at least on the number of identifiers includes any one of the following operations: Based on the number of identifiers, updating the historical vote count of the first other consensus node; Based on the number of identifiers and the priority difference, the historical vote count of the first other consensus node is updated; wherein the priority difference is obtained based on the execution priority of the N to-be-verified transaction identifiers in the first other consensus node and the execution priority in any one of the consensus nodes; Based on the number of identifiers, the priority difference and the execution sequence number, the historical votes of the first other consensus node are updated; wherein, the execution sequence number is obtained based on some difference identifiers that appear in the second identifier set but do not appear in the first identifier set, combined with the transaction execution order corresponding to the at least one candidate transaction identifier; the transaction execution order is obtained based on the transaction level associated with each of the at least one candidate transaction identifiers.

4. The method according to claim 3, wherein The updating of the historical vote count of the first other consensus node based on the number of identifiers includes: When the number of the identifiers is greater than a preset threshold, a first preset number of votes is subtracted from the historical number of votes of the first consensus node.

5. The method according to claim 3, wherein The updating of the historical vote count of the first other consensus node based on the number of identifiers and the priority difference includes: When the number of identifications is not greater than a preset number threshold, and the priority difference is greater than a preset difference threshold, a second preset number of votes is subtracted from the historical number of votes of the first consensus node.

6. The method according to claim 3, wherein The updating of the historical vote count of the first other consensus node based on the number of identifiers, the priority difference, and the execution sequence number includes: When the number of identifiers is not greater than a preset number threshold, the priority difference is not greater than a preset difference threshold, and the execution sequence number is less than a preset sequence number threshold, a third preset number of votes is subtracted from the historical number of votes of the first consensus node.

7. The method according to claim 3, wherein The updating of the historical vote count of the first other consensus node based on the number of identifiers, the priority difference, and the execution sequence number includes: When the number of identifications is not greater than a preset number threshold, the priority difference is not greater than a preset difference threshold, and the execution sequence number is not less than a preset sequence number threshold, a corresponding comprehensive evaluation value is obtained based on the number of identifications, the priority difference, and the execution sequence number; When the comprehensive evaluation value is greater than a preset evaluation threshold, a fourth preset number of votes is added to the historical number of votes of the first consensus node.

8. The method according to any one of claims 1 to 7, wherein: The at least one candidate transaction identifier includes: at least one request transaction identifier sent by each transaction object; The transaction level associated with each requested transaction identifier is obtained using the following method: Sending a request transaction identifier to the first other consensus node and at least one second other consensus node respectively; Receiving first timestamps returned by the first other consensus node and at least one second other consensus node respectively; The first timestamp represents: the time when the corresponding other consensus node puts the request transaction identifier into the first transaction pool; Obtaining a first average timestamp based on the received first timestamps, and obtaining a transaction level associated with the request transaction identifier based on the average timestamp and in combination with the transaction object level and contract level corresponding to the request transaction identifier; The transaction object level and the contract level are stored on the blockchain when the corresponding transaction object is registered.

9. The method according to claim 8, wherein The at least one candidate transaction identifier further includes: at least one shared transaction identifier sent respectively by the first other consensus node and the at least one second other consensus node; The transaction level associated with each shared transaction identifier is obtained by the following method: Receiving a shared transaction identifier sent by the first other consensus node and any other consensus node among the at least one second other consensus node; Sending a second timestamp corresponding to the time when the shared transaction identifier is placed into the second transaction pool to any other consensus node, so that any other consensus node obtains a second average timestamp based on the second timestamp and third timestamps respectively sent by other nodes in the blockchain network except the any other consensus node, and then saves the second average timestamp on the blockchain; The second average timestamp is obtained from the blockchain, and based on the second average timestamp, the transaction level associated with the shared transaction identifier is obtained in combination with the transaction object level and the contract level corresponding to the shared transaction identifier.

10. A blockchain consensus device, characterized in that: Applied to any consensus node in a blockchain network, the consensus node performs multiple rounds of leader election voting against the first other consensus node, wherein the corresponding operations of each module in each round are as follows: A data receiving module, configured to receive a first identifier set including N transaction identifiers to be verified, sent by the first other consensus node; an identifier acquisition module, configured to acquire N target transaction identifiers to form a second identifier set based on a transaction level associated with each of at least one candidate transaction identifier; each candidate transaction identifier is obtained from a transaction request received from the blockchain network; a voting update module, configured to obtain, based at least on the difference between the first set of identifiers and the second set of identifiers and in combination with the historical votes of the first other consensus node, the cumulative votes of the first other consensus node in the current round, and to receive the cumulative votes of the first other consensus node sent by at least one second other consensus node; A master node determination module is used to obtain the comprehensive votes of the first other consensus node in this round based on the accumulated votes, and determine the first other consensus node as the master node in the blockchain network when the comprehensive votes meet the preset master election conditions.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 9 is implemented.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

13. A computer program product, characterized in that When the computer program product is called by a computer, the computer is caused to execute the method according to any one of claims 1 to 9.

Images