Transaction consensus method, system, and related product

Abstract

The present application provides a transaction consensus method, a system, and a related product, capable of improving the efficiency of a consensus network performing consensus on a transaction. In specific implementation, a blockchain network comprises a plurality of blockchain nodes, some or all of the plurality of blockchain nodes constitute a consensus network, and the blockchain nodes in the consensus network comprise one master node and a plurality of slave nodes. When consensus needs to be performed on a target transaction, a client can send the target transaction to the master node and the plurality of slave nodes comprised in the consensus network. Upon receiving the target transaction, one slave node generates a transaction summary of the target transaction, and then sends the transaction summary of the target transaction to the master node. Then, the master node broadcasts the transaction summary of the target transaction to all the slave nodes in the consensus network. Upon receiving the transaction summary of the target transaction, the plurality of slave nodes in the consensus network perform consensus on the target transaction with the master node on the basis of the transaction summary of the target transaction, so as to determine the validity of the target transaction.

Description

Transaction consensus methods, systems and related products

[0001] This application claims priority to Chinese Patent Application No. 202510308238.9, filed with the State Intellectual Property Office of China on March 14, 2025, entitled “Transaction Consensus Method, System and Related Products”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of blockchain technology, and in particular to a transaction consensus method, system and related products. Background Technology

[0003] A blockchain network is a widely used decentralized network system that consists of multiple blockchain nodes that collectively maintain one or more blockchains. The blockchain maintained by these nodes is essentially a decentralized database used to store data related to one or more transactions. To ensure that the blockchain nodes in the network agree on the validity, order, and consistency of transactions on the blockchain, consensus is required.

[0004] Currently, consensus on transactions can be achieved as follows: A consensus network is formed by selecting a subset of blockchain nodes from the existing blockchain network. Then, one blockchain node is chosen as the master node from among the nodes in the consensus network, with the others acting as slave nodes. Clients on the blockchain network send transactions to be agreed upon to the master node. The master node periodically packages the received transactions into blocks and broadcasts them to all slave nodes in the consensus network, enabling all blockchain nodes to verify the transaction and reach consensus. Under high concurrency scenarios, the master node receives a large number of transactions from clients. The master node's limited bandwidth can cause delays in transaction broadcasting, thus affecting the efficiency of the consensus network in reaching consensus. Summary of the Invention

[0005] This application provides a transaction consensus method, system, and related products that can improve the efficiency of consensus networks in reaching consensus on transactions.

[0006] Firstly, this application provides a transaction consensus method. Specifically, a blockchain network includes multiple blockchain nodes, and a consensus network within the blockchain network consists of some or all of these blockchain nodes. Each blockchain node in the consensus network includes a master node and multiple slave nodes. When consensus on a target transaction is required, the client can send the target transaction to the master node and multiple slave nodes in the consensus network. If the first slave node successfully receives the target transaction, it generates a transaction digest of the target transaction and sends the transaction digest to the master node. Correspondingly, the master node sends the transaction digests of the target transaction to each slave node in the consensus network. After receiving the transaction digest, the second slave node, based on the transaction digest, reaches a consensus on the target transaction with the master node and other slave nodes in the consensus network to determine the legality of the target transaction.

[0007] In the technical solution provided in this application, the client sends the transaction requiring consensus to the master node and all slave nodes in the consensus network. This ensures that most or all nodes in the consensus network can receive the transaction to be consensused. Compared to the method where the master node broadcasts the transaction to be consensused to all slave nodes, the technical solution provided in this application reduces the bandwidth load on the master node and avoids the phenomenon that the master node's bandwidth bottleneck prevents the timely broadcast of the transaction to be consensused to other slave nodes, thus improving the efficiency of the consensus network in reaching consensus on transactions. Moreover, to prevent some slave nodes from failing to receive the transaction to be consensused, the slave nodes also synchronize the transaction reception status with the master node by sending a transaction digest. The master node then broadcasts the transaction digest of the transaction to be consensused to all slave nodes, enabling all slave nodes to confirm the transaction to be consensused. This effectively alleviates the increased consensus delay caused by some nodes missing transactions during the consensus process. Furthermore, since the master node sends a transaction digest, rather than the transaction itself, to the slave nodes, the bandwidth load on the master node can be further reduced.

[0008] In one possible implementation, before the master node sends the transaction digest of the target transaction to each slave node in the consensus network, the master node also determines that the number of blockchain nodes in the consensus network that have received the target transaction is greater than a threshold. The master node sending the transaction digest of the target transaction to each slave node in the consensus network includes the following steps: the master node packages the transaction digest of the target transaction into a block, and then sends the block to each slave node in the consensus network.

[0009] In one possible implementation, the master node can adjust the above threshold based on the number of transactions per second (TPS) processed by the consensus network.

[0010] It's understandable that setting the threshold higher leads to fewer transactions meeting the condition (i.e., the number of blockchain nodes receiving the transaction in the consensus network exceeds the threshold). Consequently, the number of transactions a block can contain is reduced, impacting the consensus network's TPS. Conversely, setting the threshold lower means that even if few blockchain nodes receive the transaction, the block will still include it. However, this results in more slave nodes needing to spend extra time requesting the transaction from other nodes, further affecting the consensus network's TPS. Therefore, adjusting the threshold based on the consensus network's TPS, and then using the threshold to determine which transaction summaries can be added to the block, can improve the overall TPS of the consensus network.

[0011] In one possible implementation, the second slave node reaches consensus on the target transaction with the master node and other slave nodes in the consensus network based on the transaction digest of the target transaction, including the following steps: the second slave node obtains the target transaction based on the transaction digest of the target transaction, and then reaches consensus on the target transaction with the master node and other slave nodes in the consensus network.

[0012] In one possible implementation, the second slave node obtains the target transaction based on the transaction digest of the target transaction, including the following steps: the second slave node obtains the target transaction from the local transaction pool based on the transaction digest of the target transaction, wherein the transaction pool of the second slave node includes transactions received by the second slave node from the client and the corresponding transaction digests.

[0013] In one possible implementation, the second slave node obtains the target transaction based on the transaction digest of the target transaction, including the following steps: the second slave node requests the target transaction from the master node or other slave nodes in the consensus network based on the transaction digest of the target transaction, so as to obtain the target transaction.

[0014] With the above implementation, even if a slave node fails to receive the transaction to be reached for consensus sent by the client, it can still obtain the transaction to be reached for consensus from the master node or other slave nodes, thus avoiding consensus delays caused by some slave nodes missing transactions during the consensus process.

[0015] In one possible implementation, the aforementioned blockchain network can be a public blockchain, a private blockchain, or a consortium blockchain.

[0016] Secondly, this application provides a transaction consensus system. Specifically, the blockchain network includes multiple blockchain nodes. The transaction consensus system includes a client and a consensus network, wherein the consensus network consists of some or all of the blockchain nodes included in the blockchain network, and the blockchain nodes in the consensus network include a master node and multiple slave nodes. Specifically, the client is used to send a target transaction to the master node and multiple slave nodes included in the consensus network. The first slave node among the multiple slave nodes is used to generate a transaction digest of the target transaction based on the target transaction and send the transaction digest of the target transaction to the master node. The master node is used to send the transaction digest of the target transaction to all slave nodes in the consensus network. The second slave node among the multiple slave nodes is used to reach a consensus on the target transaction with the master node and other slave nodes in the consensus network based on the transaction digest of the target transaction, so as to determine the legality of the target transaction.

[0017] In one possible implementation, the master node is also used to determine if the number of blockchain nodes in the consensus network that have received the target transaction is greater than a threshold.

[0018] In one possible implementation, the master node is also used to adjust the aforementioned threshold based on the consensus network's TPS.

[0019] In one possible implementation, the second slave node is used to obtain the target transaction based on the transaction digest of the target transaction, and to reach consensus on the target transaction with the master node and other slave nodes in the consensus network.

[0020] In one possible implementation, the second slave node is used to retrieve the target transaction from the local transaction pool based on the transaction digest of the target transaction. The transaction pool of the second slave node includes transactions received by the second slave node from the client and their corresponding transaction digests.

[0021] In one possible implementation, the second slave node is used to request the target transaction from the master node or other slave nodes in the consensus network based on the transaction digest of the target transaction, so as to obtain the target transaction.

[0022] In one possible implementation, the aforementioned blockchain network can be a public blockchain, a private blockchain, or a consortium blockchain.

[0023] Thirdly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, causing the computing device cluster to perform some or all of the methods described in the first aspect and any implementation thereof.

[0024] Fourthly, this application provides a computer program product containing instructions. This computer program product may be a software or program product containing instructions capable of running on a cluster of computing devices or stored on any available medium. When the computer program product runs on a cluster of computing devices, the cluster of computing devices performs some or all of the methods described in the first aspect and any implementation thereof.

[0025] Fifthly, this application provides a computer-readable storage medium. The computer storage medium includes computer program instructions that, when executed by a cluster of computing devices, perform some or all of the methods described in the first aspect and any implementation thereof. Attached Figure Description

[0026] Figure 1 is a schematic diagram of a transaction consensus scenario provided in this application;

[0027] Figure 2 is a schematic diagram of a blockchain network deployment method provided in this application;

[0028] Figure 3 is a flowchart illustrating a transaction consensus method provided in this application;

[0029] Figure 4 is a schematic diagram of the structure of a transaction consensus system provided in this application;

[0030] Figure 5 is a schematic diagram of the structure of a computing device cluster provided in this application;

[0031] Figure 6 is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0032] The technical solution provided in this application will be described below with reference to the accompanying drawings.

[0033] Referring to Figure 1, Figure 1 illustrates a transaction consensus scenario to which this application applies. As shown in Figure 1, this scenario includes a client 100 and a blockchain network 200, wherein the client 100 and the blockchain network 200 are connected via a network, which can be a wide area network (WAN) or a local area network (LAN). For example, the WAN includes one or more of the following: leased line, Internet, multiprotocol label switching (MPLS) network, virtual private network (VPN), etc.; the LAN includes one or more of the following: Ethernet, wireless local area network (WLAN), virtual local area network (VLAN), etc.

[0034] Client 100 is software or application (APP) used to manage transactions. For example, client 100 can be used to create transactions, submit transactions to blockchain network 200, query transaction execution status, etc. The transactions here can include one or more types of transactions that can be implemented through blockchain, such as transfer transactions, token transactions, data sharing transactions, and permission management transactions.

[0035] In a specific implementation, the client 100 can be deployed on a single computing device or a cluster of computing devices consisting of multiple computing devices. The computing devices here can include servers, such as central servers or edge servers in cloud data centers or local servers in local data centers, and can also include terminal devices such as desktop computers, laptops, smartphones, and tablets. This application does not limit this.

[0036] It is worth noting that the number of clients 100 that establish network connections with the blockchain network 200 can be one or more. For ease of description, Figure 1 shows four clients 100, namely client C1, client C2, client C3 and client C4. These four clients 100 are clients of organization 1, organization 2, organization 3 and organization 4, which will be discussed later.

[0037] Blockchain network 200 is a network system that utilizes a block-chain data structure to verify and store data, a distributed node consensus algorithm to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script code to program and manipulate data. Specifically, blockchain network 200 includes multiple blockchain nodes, which can be implemented using one or more computing devices such as servers, virtual machines, containers, desktop computers, and embedded devices. The blockchain nodes in blockchain network 200 are used to maintain the blockchain, which uses a block-chain data structure to store transaction data. Therefore, the maintenance of the blockchain by the blockchain nodes is reflected in multiple aspects such as storing transaction data, verifying transaction data, and disseminating transaction data. In blockchain network 200, some or all of the blockchain nodes can constitute a consensus network 210, which can use a consensus algorithm to ensure the security and transparency of transaction data on the blockchain.

[0038] It is worth noting that this application does not limit the type of blockchain network 200. For example, blockchain network 200 can be a public blockchain, which is a completely open blockchain network where any user can participate. All transaction data is public and transparent, and supports viewing and verification by any user. It is typically suitable for decentralized and transparent transaction scenarios such as Bitcoin and Ethereum. As another example, blockchain network 200 can also be a private blockchain, which is a blockchain network controlled by a single organization (such as an enterprise). Only authorized users can participate, and transaction data on a private blockchain is usually private and not publicly disclosed, typically suitable for internal organizational use. Furthermore, blockchain network 200 can also be a consortium blockchain, which is a blockchain network jointly managed by multiple organizations. Only authorized organizations can participate, typically suitable for collaborative scenarios between multiple organizations.

[0039] Next, we will introduce blockchain network 200 using consortium blockchain as an example.

[0040] As shown in Figure 1, the blockchain network 200 is jointly managed by multiple organizations. For ease of description, four organizations are shown in the figure (Organization 1, Organization 2, Organization 3, and Organization 4). However, in actual applications, the number of organizations managing the blockchain network 200 can be more or less, and this application does not limit this. Specifically, Organization 1, Organization 2, Organization 3, and Organization 4 can be enterprise departments. Through the blockchain network 200, each organization can share its local business data with other organizations. Correspondingly, after receiving the shared business data from other organizations, each organization can analyze and process this business data to ensure the normal operation of the enterprise. Alternatively, Organization 1, Organization 2, Organization 3, and Organization 4 can also be financial institutions, realizing cross-institutional payments and settlements through the blockchain network 200. Or, Organization 1, Organization 2, Organization 3, and Organization 4 can also be enterprises and different suppliers, realizing contract management, etc., through the blockchain network 200. In addition, Organization 1, Organization 2, Organization 3, and Organization 4 can also have other types, and this application does not limit this.

[0041] When the blockchain network 200 is jointly managed by four organizations, the blockchain network 200 may include four blockchain node clusters, namely blockchain node cluster 1, blockchain node cluster 2, blockchain node cluster 3, and blockchain node cluster 4. These four blockchain node clusters belong to organizations 1, 2, 3, and 4, respectively. That is, organization 1 is responsible for managing blockchain node cluster 1, organization 2 is responsible for managing blockchain node cluster 2, organization 3 is responsible for managing blockchain node cluster 3, and organization 4 is responsible for managing blockchain node cluster 4. Each blockchain node cluster includes one or more blockchain nodes. When a blockchain node cluster includes multiple blockchain nodes, these blockchain nodes are connected through a network. This network can be a wired network, such as Ethernet, cable network, or fiber optic network; it can also be a wireless network, such as cellular network or wireless local area network (Wi-Fi); or it can be the Internet or local area network (LAN), etc. This application does not limit the type of network.

[0042] To ensure the legitimacy of transactions between Organization 1, Organization 2, Organization 3, and Organization 4, each organization selects one or more blockchain nodes from its respective blockchain node cluster as consensus nodes to form consensus network 210. As shown in Figure 1, consensus network 210 includes multiple consensus nodes; for ease of description, only four consensus nodes are shown in the figure. These four consensus nodes are selected from the aforementioned four blockchain node clusters. The consensus nodes in consensus network 210 determine the validity of transactions through a consensus algorithm. This consensus algorithm ensures that most or all consensus nodes in consensus network 210 agree on the validity, order, and consistency of transaction data in the blockchain, preventing issues such as transaction data tampering and double-spending. By defining the interaction rules and decision-making process between consensus nodes, it ensures that transaction data in the blockchain remains secure and transparent even in untrusted environments.

[0043] As one possible implementation, the consensus algorithm used in Consensus Network 210 is a master-based consensus algorithm. A master-based consensus algorithm is a special type of consensus algorithm where a specific consensus node is designated to be responsible for assembling a batch of transactions into blocks and submitting them to all consensus nodes for consensus. This node is called the master node, and the other nodes that vote on the blocks assembled by the master node are called slave nodes. The master-based consensus algorithm used in Consensus Network 210 can include one or more of the following: Byzantine fault tolerance (BFT) algorithm and crash fault tolerance (CFT) algorithm. Specifically, BFT algorithms can include one or more of the following: practical byzantine fault tolerance (PBFT) algorithm, HotStuff algorithm, etc., and CFT algorithms can include one or more of the following: Raft algorithm, Paxos algorithm, etc.

[0044] Based on the master-slave consensus algorithm, the consensus nodes in consensus network 210 can be divided into two categories: master nodes and slave nodes. As shown in Figure 1, consensus network 210 includes master node L, slave node F1, slave node F2, and slave node F3. Master node L is selected from the four consensus nodes in consensus network 210 based on the selection mechanism specified in the master-slave consensus algorithm (such as random selection, weighted voting selection, rotation selection, etc.) (Figure 1 shows that master node L belongs to blockchain node cluster 1). Correspondingly, the other three consensus nodes are slave nodes F1, F2, and F3, respectively (Figure 1 shows that slave node F1 belongs to blockchain node cluster 2, slave node F2 belongs to blockchain node cluster 3, and slave node F3 belongs to blockchain node cluster 4). It is understood that, in addition to the division of master nodes and slave nodes shown in Figure 1, consensus nodes in consensus network 210 can also be divided in other ways. For example, master node L belongs to blockchain node cluster 2, slave node F1 belongs to blockchain node cluster 3, slave node F2 belongs to blockchain node cluster 4, and slave node F3 belongs to blockchain node cluster 1. This application does not limit this, but for ease of description, the following embodiments are all described with the division method shown in Figure 1.

[0045] It is worth noting that, in addition to the consortium blockchain deployment shown in Figure 1, the blockchain network 200 can also be deployed as a public blockchain, private blockchain, or other types of blockchain networks according to business needs. For ease of description, the following embodiments are described using the deployment form shown in Figure 1.

[0046] In the scenario shown in Figure 1, client 100 sends a transaction requiring consensus to all consensus nodes in consensus network 210. Consensus nodes receiving the transaction generate a transaction digest. When the receiving node is a slave node, it periodically sends the generated transaction digest to master node L. Master node L also periodically determines the transaction reception status of each consensus node based on the received transaction digests; each consensus node may receive one or more transactions. Master node L also determines at least one transaction that meets preset conditions based on the transaction reception status of each consensus node. Then, master node L verifies the transaction digests of the at least one transaction that meets the preset conditions. Upon successful verification, it assembles these transaction digests into a block and sends the block to slave nodes F1, F2, and F3 respectively. Each slave node, upon receiving the block, can determine at least one transaction based on the at least one transaction digest in the block, assemble the determined at least one transaction into a new block, verify the new block, and thus reach a consensus with master node L on the legality of the new block. This completes the consensus on at least one transaction contained in the new block. Furthermore, once the consensus nodes in consensus network 210 reach a consensus on the legitimacy of the new block, they will send the new block to other blockchain nodes in blockchain network 200. The other blockchain nodes will then verify the new block. Once the verification is successful, the new block will be added to the local blockchain, thus completing at least one transaction between organizations.

[0047] In a specific implementation, the aforementioned blockchain network 200 can be deployed on a cluster of computing devices consisting of multiple computing devices. These computing devices can include servers, such as central servers, edge servers in cloud data centers, or local servers in local data centers, as well as terminal devices such as desktop computers, laptops, and smartphones. They can also include embedded devices, IoT devices, network attached storage (NAS) devices, etc. This application does not limit the scope of these devices.

[0048] As one possible implementation, as shown in Figure 2, the blockchain network 200 can be deployed in a data center. In this case, the blockchain network 200 can be provided as a cloud service to various organizations based on the basic resources (including computing resources, storage resources, and network resources) provided by the data center. Organization employees can register accounts on the cloud management platform, log in through their accounts, and purchase the aforementioned cloud services. After a successful purchase, the organization can use the blockchain network 200 to conduct transactions with other organizations.

[0049] It is understood that Figure 2 is merely an example illustrating one possible deployment method of the blockchain network 200. In practical applications, the blockchain network 200 can be flexibly deployed according to actual business needs, and this application does not limit this.

[0050] The functions of the blockchain network 200 will be described in more detail below with reference to Figure 3. Referring to Figure 3, Figure 3 shows a flowchart of a transaction consensus method. As shown in Figure 3, the transaction consensus method 300 includes the following steps:

[0051] Step 301: Client 100 sends one or more transactions to all consensus nodes in consensus network 210.

[0052] In this step, client 100 may include one or more of clients C1, C2, C3, and C4. Accordingly, the aforementioned one or more transactions may originate from one or more of clients C1, C2, C3, and C4. Furthermore, the aforementioned one or more transactions may be sent by one or more clients 100 within the same time period.

[0053] As one possible implementation, the transactions sent by client 100 to all consensus nodes in consensus network 210 can be endorsed and successfully verified transactions. Here, endorsement refers to the process of verifying the validity of a transaction. The following example (hereinafter referred to as "Transaction 1") illustrates the endorsement process:

[0054] Step ①: Client 100 sends transaction 1 to one or more blockchain nodes in blockchain network 200. Accordingly, the one or more blockchain nodes receive transaction 1 sent by client 100.

[0055] Transaction 1 includes various transaction data required to execute Transaction 1, such as one or more of the following: the identifier of Transaction 1, the transaction type, the transaction time, the identifiers of the two parties to the transaction (such as the names of organizations), the name of the smart contract corresponding to Transaction 1, the functions and parameters called by the smart contract, etc. The aforementioned smart contract is a code-implemented contract that can automatically execute under specific conditions. It defines the business logic and execution rules of Transaction 1 and is used to simulate the execution of Transaction 1.

[0056] In its implementation, the smart contract corresponding to Transaction 1 also includes an endorsement strategy. This strategy instructs which blockchain nodes in blockchain network 200 need to participate in the endorsement verification of Transaction 1, how these nodes verify Transaction 1, and which nodes' verification is required for Transaction 1 to be considered valid. Therefore, client 100 can select one or more blockchain nodes from the blockchain node cluster of its corresponding organization based on the endorsement strategy, and then send a transaction proposal to the selected nodes. The selected nodes may or may not include consensus nodes in consensus network 210. For example, assuming Transaction 1 is initiated by organization 1, the blockchain nodes participating in the endorsement verification of Transaction 1 can include one or more blockchain nodes in blockchain node cluster 1, such as master node L in consensus network 210, or all blockchain nodes in blockchain node cluster 1 except for master node L.

[0057] Step ②: The aforementioned one or more blockchain nodes endorse transaction 1, resulting in one or more endorsement results for transaction 1.

[0058] Since each of the aforementioned blockchain nodes generates an endorsement result when endorsing transaction 1, the one or more endorsement results for transaction 1 include the endorsement results of each of the aforementioned blockchain nodes for transaction 1. Next, taking one of the aforementioned blockchain nodes (hereinafter referred to as "blockchain node 1") as an example, blockchain node 1 can endorse transaction 1 through the following steps:

[0059] Blockchain node 1 is configured with the smart contract corresponding to transaction 1. Therefore, blockchain node 1 can determine the smart contract corresponding to transaction 1 based on the name of the smart contract carried in transaction 1, and then simulate the execution of transaction 1 by calling that smart contract, thus obtaining the endorsement result of blockchain node 1 for transaction 1. The aforementioned endorsement result may include one or more of the following: the identifier of transaction 1, the transaction execution status, the transaction execution simulation result, the signature of the ledger node, etc. Among them, the transaction execution status includes two cases: success or failure. Successful transaction execution means that transaction 1 has passed verification, and failure means that transaction 1 has not passed verification; the transaction execution simulation result includes the transaction return value (i.e., the value returned after simulating the execution of transaction 1, such as whether organization 1 has received the business data reported by organization 2), the set of read operations (including the data read during the transaction execution process), and the set of write operations (including the data that needs to be modified after the transaction execution), etc.; the signature of blockchain node 1 includes the identity information of blockchain node 1 (such as the certificate or identifier of blockchain node 1) and the signature of blockchain node 1 on the simulation result of transaction execution, etc.

[0060] It is understandable that when multiple blockchain nodes participate in endorsing transaction 1, the process of other blockchain nodes endorsing transaction 1 is similar to the process of blockchain node 1 endorsing transaction 1. For the sake of simplicity, it will not be elaborated here.

[0061] Step ③: The aforementioned one or more blockchain nodes send their respective endorsement results for transaction 1 to client 100. Accordingly, client 100 receives one or more endorsement results for transaction 1.

[0062] Step 4: Client 100 determines that Transaction 1 is valid based on one or more endorsement results of Transaction 1.

[0063] In specific implementation, when only one blockchain node endorses transaction 1, the client 100 can directly determine whether transaction 1 is valid based on the endorsement result returned by that blockchain node. Specifically, if the transaction execution status in the endorsement result indicates that transaction 1 has passed verification, then transaction 1 is determined to be valid; if the transaction execution status in the endorsement result indicates that transaction 1 has not passed verification, then transaction 1 is determined to be invalid. When multiple blockchain nodes endorse transaction 1, the client 100 can determine whether transaction 1 is valid based on the endorsement results returned by these multiple blockchain nodes. Specifically, if the multiple endorsement results satisfy the endorsement strategy (e.g., transaction 1 has passed verification by a preset number of blockchain nodes, or transaction 1 has passed verification by a preset number of blockchain nodes, or the weight of the blockchain nodes that have verified transaction 1 is greater than a preset weight), then transaction 1 is determined to be valid; if the multiple endorsement results do not satisfy the endorsement strategy, then transaction 1 is determined to be invalid.

[0064] It is worth noting that although this embodiment assumes transaction 1 to be valid, in actual applications, transaction 1 can also be invalid. When transaction 1 is invalid, step ⑤ below will not be executed.

[0065] Step 5: Client 100 assembles Transaction 1 and its corresponding one or more endorsement results. The assembled result is the transaction that Client 100 needs to send to all consensus nodes in consensus network 210 (to distinguish it from Transaction 1 in step 1, the assembled result will be referred to as "Transaction 1'" below).

[0066] In a specific implementation, client 100 can combine transaction 1 and its corresponding one or more endorsement results in a certain order to complete the assembly of transaction 1 and its corresponding one or more endorsement results to obtain transaction 1', wherein transaction 1' includes transaction 1 and its corresponding one or more endorsement results.

[0067] By following steps ① to ⑤ above, the endorsement of transaction 1 can be completed, resulting in transaction 1' that client 100 needs to send to all consensus nodes in consensus network 210. Furthermore, other transactions awaiting consensus that client 100 sends to all consensus nodes in consensus network 210 can also be obtained through the above steps; for the sake of brevity, they will not be elaborated upon here.

[0068] It is worth noting that the transactions sent by client 100 to all consensus nodes in consensus network 210 in step 301 can be either endorsed and verified transactions or transactions that have not been endorsed. For example, client 100 can send transaction 1 directly to all consensus nodes in consensus network 210, or it can first endorse transaction 1 through steps ① to ⑤ above to obtain transaction 1′, and then send transaction 1′ to all consensus nodes in consensus network 210.

[0069] Furthermore, for any transaction sent by client 100, the reception status of any consensus node in consensus network 210 may include: normal reception or abnormal reception. Normal reception means that the consensus node receives the transaction and stores it in its local transaction pool, where the transaction pool refers to the storage space within the consensus node used to store transactions. Abnormal reception includes reception failure and / or discarding after reception. Reception failure means that the consensus node does not receive the transaction for an extended period, which may be caused by network failure or latency between the consensus node and client 100. Discarding after reception means that the consensus node discards the transaction after receiving it because its local transaction pool is full. Moreover, the reception status of different consensus nodes in consensus network 210 for the same transaction sent by client 100 may be the same or different. For example, all consensus nodes in consensus network 210 may receive the transaction normally, or all consensus nodes in consensus network 210 may fail to receive the transaction, or some consensus nodes may receive the transaction normally while others receive it abnormally. For ease of description, "normal reception" will be referred to as "the consensus node successfully received the transaction" below.

[0070] Step 302: Each consensus node in the consensus network 210 generates a corresponding transaction digest based on the successfully received transactions.

[0071] A transaction summary is a concise description of a transaction, used to quickly verify its integrity and uniqueness. A transaction summary can be represented by a hash value, which is a string obtained by hashing all the content contained in the transaction.

[0072] Taking a slave node F1 in a consensus network 210 as an example, assuming that slave node F1 successfully receives transaction 2 sent by client 100, slave node F1 can generate a transaction digest of the transaction through the following steps: Slave node F1 serializes all the contents of transaction 2 according to a preset order and preset format to obtain a serialization result. The preset order and preset format used here can be set by the user or by slave node F1. Then, slave node F1 uses a hash algorithm to perform hash calculation on the above serialization result. The hash value obtained is the transaction digest of transaction 2. The hash algorithm used here can be any existing algorithm used in the industry for calculating hash values, such as the secure hash algorithm (SHA), message digest algorithm 5 (MD5), RACE integrity primitives evaluation message digest (RIPEMD), etc. This application does not make specific limitations on this.

[0073] It is understandable that other transactions successfully received by node F1, as well as transactions successfully received by other consensus nodes in consensus network 210 (including master node L, slave node F2, and slave node F3), can all generate corresponding transaction digests using the approach mentioned above. For simplicity, this will not be elaborated further here. Furthermore, for the same transaction, different consensus nodes in consensus network 210 use the same preset order, preset format, and hash algorithm when generating the transaction digest, thus ensuring that the transaction digests generated by different consensus nodes are consistent.

[0074] In step 303, each slave node in consensus network 210 sends its generated transaction digest to master node L. Correspondingly, master node L receives transaction digests from multiple slave nodes.

[0075] Step 304: The master node L determines the reception status of each transaction in one or more transactions sent by the client 100 based on the transaction digests sent by each slave node.

[0076] The transaction reception status is used to reflect which consensus nodes in consensus network 210 have successfully received the transaction. In specific implementation, the transaction reception status can be represented by the identifiers of the consensus nodes in consensus network 210 that have successfully received the transaction. The identifiers of the consensus nodes may include one or more of the following information that can uniquely identify the consensus node: the consensus node's network address (such as Internet Protocol address and port number), the consensus node's ID, the consensus node's digital certificate, etc.

[0077] For example, suppose client 100 sends transactions 2, 3, 4, and 5 to all consensus nodes in consensus network 210. Master node L, slave nodes F1, F2, and F3 successfully receive transaction 2; master node L, slave nodes F1, and F2 successfully receive transaction 3; master node L, slave nodes F2, and F3 successfully receive transaction 4; and slave node F3 successfully receives transaction 5. Then, the reception status of transaction 2 can be represented as [master node L, slave node F1, slave node F2, slave node F3], the reception status of transaction 3 can be represented as [master node L, slave node F1, slave node F2], the reception status of transaction 4 can be represented as [master node L, slave node F2, slave node F3], and the reception status of transaction 5 can be represented as [slave node F3].

[0078] In its implementation, master node L can determine the reception status of one or more transactions sent by client 100 through the following steps: Master node L obtains multiple transaction digests, including those sent by slave nodes F1, F2, and F3, as well as those generated by master node L based on the received transactions. Then, master node L compares these multiple transaction digests to determine one or more transaction digest sets. Each transaction digest set includes one or more transaction digests. When a transaction digest set includes multiple transaction digests, these multiple transaction digests are considered matched. Transaction digest matching here means that the similarity between the transaction digests is greater than a preset similarity, which can be set by the user or by master node L. For each transaction digest set, master node L determines the source of each transaction digest contained in the set. The source of the transaction digest includes one or more of the following: generated by master node L, sent by slave node F1, sent by slave node F2, and sent by slave node F3. Thus, master node L can determine the reception status of the transactions corresponding to the transaction digest set, i.e., which consensus nodes in consensus network 210 successfully received the transaction.

[0079] Using the example above, since master node L, slave nodes F1, F2, and F3 successfully received transaction 2, master node L, slave nodes F1, and F2 successfully received transaction 3, master node L, slave nodes F2, and F3 successfully received transaction 4, and slave node F3 successfully received transaction 5, master node L will generate transaction summaries for transaction 2, transaction 3, and transaction 4; slave node F1 will generate transaction summaries for transaction 2 and transaction 3; slave node F2 will generate transaction summaries for transaction 2, transaction 3, and transaction 4; and slave node F3 will generate transaction summaries for transaction 2, transaction 4, and transaction 5. Correspondingly, master node L will receive transaction summaries for transaction 2 and transaction 3 sent by slave node F1, transaction summaries for transaction 2, transaction 3, and transaction 4 sent by slave node F2, and transaction summaries for transaction 2, transaction 4, and transaction 5 sent by slave node F3. Subsequently, master node L determines four transaction digest sets by comparing the transaction digests sent by slave node F1, slave node F2, slave node F3, and the transaction digest generated by master node L: Transaction Digest Set 1, Transaction Digest Set 2, Transaction Digest Set 3, and Transaction Digest Set 4. Transaction Digest Set 1 includes the transaction digests of Transaction 2 generated by master node L, Transaction 2 sent by slave node F1, Transaction 2 sent by slave node F2, and Transaction 2 sent by slave node F3. Transaction Digest Set 2 includes the transaction digests of Transaction 3 generated by master node L, Transaction 3 sent by slave node F1, and Transaction 3 sent by slave node F2. Transaction Digest Set 3 includes the transaction digests of Transaction 4 generated by master node L, Transaction 4 sent by slave node F2, and Transaction 4 sent by slave node F3. Transaction Digest Set 4 only includes the transaction digest of Transaction 5 sent by slave node F3. Based on the four transaction digest sets mentioned above, it can be determined that master node L, slave nodes F1, F2, and F3 successfully received transaction 2; master node L, slave nodes F1, and F2 successfully received transaction 3; master node L, slave nodes F2, and F3 successfully received transaction 4; and slave node F3 successfully received transaction 5. Therefore, the reception status of transactions 2, 3, 4, and 5 can be obtained.

[0080] It is worth noting that since transaction digests can be represented by hash values, the "comparison of transaction digests" involved in the above steps can be implemented in various ways, such as string comparison, bit-level comparison, byte-by-byte comparison, and bitmasking. This application does not limit the specific methods used in this regard.

[0081] Step 305: Master node L generates the first block based on the reception status of each determined transaction.

[0082] In practice, the master node L determines at least one transaction that meets preset conditions based on the receipt status of each transaction. Then, it assembles the transaction digests of these at least one transaction that meets the preset conditions to generate a first block. The first block includes the transaction digests of the at least one transaction that meets the preset conditions. Here, assembly refers to combining the transaction digests of the at least one transaction that meets the preset conditions into a data unit (i.e., a block) in a certain order (such as the order of transaction time, transaction priority, etc.). It is worth noting that the "first" in "first block" is a prefix, used only to distinguish it from the second block mentioned later.

[0083] The "preset conditions" in the above steps include one or more of the following:

[0084] ① The number of consensus nodes that successfully receive transactions in consensus network 210 is greater than the first threshold.

[0085] The first threshold can be set by the user or by the master node L. When the first threshold is set by the master node L, the master node L can set the first threshold according to the master-based consensus algorithm adopted by the consensus network 210. Specifically, if the master-based consensus algorithm adopted by the consensus network 210 is the CFT algorithm, the first threshold can be set to be greater than half of the total number of consensus nodes included in the consensus network 210. This setting has been proven through extensive research. If the master-based consensus algorithm adopted by the consensus network 210 is the BFT algorithm, the first threshold can be set to be greater than one-third of the total number of consensus nodes included in the consensus network 210. This setting takes into account the characteristics of the BFT algorithm. Specifically, the BFT algorithm supports the existence of one-third malicious nodes in the consensus network 210. Malicious nodes refer to slave nodes that send false transaction digests to the master node. Since there is no corresponding transaction for the false transaction digest, consensus on the transaction corresponding to the false transaction digest is invalid. To avoid consensus on the transaction corresponding to the false transaction digest, the first threshold needs to be greater than one-third of the total number of consensus nodes included in the consensus network 210.

[0086] In addition, the master node L can set a first threshold based on the TPS of the consensus network 210. The TPS of the consensus network 210 is an important indicator for measuring the performance of the consensus algorithm used by the consensus network 210. It is calculated by dividing the number of transactions in a block by the time cost for the consensus nodes to reach consensus on the block. The higher the value, the more efficient the consensus network 210 is in reaching consensus on the block.

[0087] The relationship between the TPS of consensus network 210 and the first threshold is as follows: A higher first threshold results in fewer transactions meeting the preset conditions, leading to fewer transactions in the first block and thus affecting the TPS of consensus network 210. Conversely, a lower first threshold means that even if few consensus nodes receive the transaction, the first block will still include it. However, this will cause more consensus nodes to spend extra time requesting the transaction from other nodes in subsequent step 306, further affecting the TPS of consensus network 210. It can be seen that the TPS of consensus network 210 is affected by the first threshold. Therefore, the master node L can adjust the first threshold in reverse based on the TPS of consensus network 210 to ensure that consensus network 210 has a high TPS.

[0088] ② The transaction pool of master node L contains transactions.

[0089] The transactions stored in the transaction pool of master node L can include transactions that master node L successfully receives from client 100 and stores directly in the local transaction pool, or transactions that master node L requests from one or more slave nodes in consensus network 210 and stores in the local transaction pool. Specifically, as mentioned above, for transactions sent by client 100 to all consensus nodes in consensus network 210, master node L may receive them normally or abnormally. When the reception is normal, it means that master node L has successfully received the transaction sent by client 100, and in this case, master node L will directly store the transaction in the local transaction pool. When the reception is abnormal, it means that master node L has not received (or has received and discarded) the transaction sent by client 100, and in this case, master node L can request the transaction from a slave node in consensus network 210 that successfully received the transaction and store the transaction in the local transaction pool.

[0090] As one possible implementation, the master node L can successfully receive a transaction request from a slave node in the consensus network 210 through the following steps: Based on the transaction reception status, the master node L determines which slave nodes in the consensus network 210 have successfully received the transaction, and then sends a request message containing a transaction digest to one or more of the determined slave nodes. Upon receiving the request message, the aforementioned one or more slave nodes retrieve the corresponding transaction from their local transaction pool based on the transaction digest carried in the request message (the specific implementation can be found in the description of step ① in step 307 below; for brevity, it will not be elaborated here), and then send the retrieved transaction to the master node L, thereby allowing the master node L to obtain the transaction.

[0091] ③ The transaction is legal.

[0092] In practice, master node L can determine the legitimacy of a transaction by verifying one or more of the following: whether the transaction format meets the requirements, whether the transaction signature is valid, whether the transaction source exists, whether the transaction output exists, and whether the transaction conforms to the rules of the blockchain. In addition, master node L can verify many other things, which will not be elaborated on here.

[0093] As one possible implementation, after successfully receiving a transaction from client 100 or requesting a transaction from one or more slave nodes, master node L can first perform a validity check on the transaction. If the transaction is valid, it is stored in the local transaction pool; if the transaction is invalid, it is discarded. In this way, it can be guaranteed that all transactions stored in the transaction pool of master node L are valid.

[0094] In step 306, the master node L verifies the first block. After successful verification, it sends the first block to all slave nodes in the consensus network 210. Accordingly, each slave node in the consensus network 210 receives the first block sent by the master node L.

[0095] In the specific implementation, the master node L needs to verify whether the block format of the first block meets the requirements (such as whether it contains a block header, block body, transaction list, etc.), whether the size of the first block is within the maximum allowed range, and whether the fields contained in the block header of the first block (such as timestamp, hash value of the first block, hash value of the previous block, etc.) are complete and meet the requirements, etc. This application does not limit this. After the verification is successful, the master node L then sends the first block to the slave nodes F1, F2, and F3.

[0096] It is worth noting that if the first block fails to pass verification, the master node L will not send the first block to all slave nodes in the consensus network 210. However, for ease of description, the following embodiments will use the example of the first block passing verification for subsequent introduction.

[0097] Step 307: Each slave node in consensus network 210 generates a second block based on the first block.

[0098] Taking slave node F1 as an example, slave node F1 can construct the second block through the following steps: Slave node F1 parses the first block to obtain at least one transaction digest contained in the first block, then obtains the transactions corresponding to these transaction digests based on the at least one transaction digest, and then assembles the at least one transaction obtained to generate the second block. The second block includes the at least one transaction mentioned above. Here, assembly refers to combining the at least one transaction mentioned above into a data unit (i.e., a block) in a certain order (such as the order of transaction time, the order of transaction priority, etc.).

[0099] The step described above, "from node F1 obtaining the transactions corresponding to at least one transaction digest," can be implemented through the following sub-steps (i.e., steps ① to ⑧). It should be noted that, for simplicity, steps ① to ⑧ below are based on a single transaction digest (hereinafter referred to as "transaction digest 1"), illustrating how node F1 determines the transaction corresponding to transaction digest 1. For other transaction digests in other blocks, node F1 can refer to the approach described in steps ① to ⑧ below to determine the corresponding transactions; this application will not elaborate further on this.

[0100] Step ①: Node F1 checks whether the transaction corresponding to transaction digest 1 is stored in its local transaction pool. If yes, proceed to step ②; otherwise, proceed to steps ③ and ④.

[0101] In the specific implementation, after node F1 successfully receives a transaction sent by client 100, in addition to calculating the transaction digest, it also stores the transaction and its transaction digest in the local transaction pool. Therefore, the transaction pool of node F1 stores one or more transactions successfully received by node F1 from client 100 and their corresponding transaction digests. The one or more transactions successfully received by node F1 from client 100 and their corresponding transaction digests can be stored in a key-value table.

[0102] Therefore, node F1 can compare transaction digest 1 with one or more transaction digests in the local transaction pool. If transaction digest 1 matches a transaction digest in the local transaction pool, it can be determined that the local transaction pool stores the transaction corresponding to transaction digest 1. Conversely, if transaction digest 1 does not match any of the transaction digests in the local transaction pool, it can be determined that the local transaction pool does not store the transaction corresponding to transaction digest 1.

[0103] It is understandable that regarding the transaction corresponding to transaction digest 1 sent by client 100, slave node F1 may receive it normally or abnormally. When the reception is normal, it means that slave node F1 has successfully received the transaction corresponding to transaction digest 1. Accordingly, slave node F1's transaction pool stores transaction digest 1 and its corresponding transaction, so slave node F1 can directly obtain the transaction corresponding to transaction digest 1 from its local transaction pool (i.e., step ②). Conversely, when the reception is abnormal, it means that slave node F1's transaction pool does not store transaction digest 1 and its corresponding transaction, thus causing slave node F1 to be unable to directly obtain the transaction corresponding to transaction digest 1 from its local transaction pool based on transaction digest 1. In this case, since the transaction pools of other consensus nodes in consensus network 210 (including one or more of master node L, slave node F2, and slave node F3) store transaction digest 1 and its corresponding transaction, slave node F1 can request the transaction corresponding to transaction digest 1 from these consensus nodes. Furthermore, since the transaction pool of master node L typically stores transactions corresponding to all transaction digests in the first block, when slave node F1 is missing a transaction corresponding to transaction digest 1, slave node F1 can first request the transaction corresponding to transaction digest 1 from master node L (i.e., step ③). When master node L is also missing a transaction corresponding to transaction digest 1, slave node F1 can first request the transaction corresponding to transaction digest 1 from other slave nodes (i.e., step ⑥).

[0104] Step ②: Obtain the transaction corresponding to transaction summary 1 from the local transaction pool from node F1.

[0105] In a specific implementation, when the slave node F1 determines that transaction digest 1 matches a certain transaction digest in the local transaction pool, the slave node F1 can further obtain the transaction corresponding to the matching transaction digest from the local transaction pool based on the matching transaction digest. This transaction is the transaction corresponding to transaction digest 1.

[0106] As one possible implementation, when the transaction pool of slave node F1 stores one or more transactions received by slave node F1 from client 100 and their corresponding transaction summaries in a key-value table, slave node F1 can directly query the key-value table to obtain the transaction corresponding to transaction summary 1 from the local transaction pool, thus quickly obtaining the transaction corresponding to transaction summary 1.

[0107] Step 3: Node F1 sends a request message to master node L to request the transaction corresponding to transaction digest 1. Accordingly, master node L receives the request message sent by node F1.

[0108] Step 4: The master node L determines whether the local transaction pool stores the transaction corresponding to transaction digest 1 based on the request message. If yes, proceed to step 5; otherwise, proceed to steps 6 and 7.

[0109] In the specific implementation, the aforementioned request message carries transaction digest 1. Furthermore, similar to slave node F1, after receiving a transaction (which can include those sent by client 100 or those requested from slave nodes), master node L also stores the transaction and its transaction digest in its local transaction pool. Therefore, master node L's transaction pool stores one or more transactions received by master node L and their corresponding transaction digests. Master node L can then determine whether the transaction corresponding to transaction digest 1 is stored in its local transaction pool based on transaction digest 1 carried in the request message. The specific implementation process is similar to step ① above, where "slave node F1 determines whether the transaction corresponding to transaction digest 1 is stored in its local transaction pool based on transaction digest 1." For simplicity, this will not be elaborated further here.

[0110] Step 5: Master node L retrieves the digest corresponding to transaction digest 1 from the local transaction pool and sends the transaction corresponding to transaction digest 1 to slave node F1. Correspondingly, slave node F1 receives the transaction corresponding to transaction digest 1 sent by master node L.

[0111] It is understandable that the process by which master node L obtains the digest corresponding to transaction digest 1 from the local transaction pool is similar to step ② above. For the sake of brevity, it will not be described in detail here.

[0112] Step 6: Node F1 sends a request message to other slave nodes in consensus network 210 to request the transaction corresponding to transaction digest 1. Correspondingly, the other slave nodes receive the request message sent by node F1.

[0113] In a specific implementation, other slave nodes can be one or more slave nodes selected by slave node F1 from all slave nodes included in the consensus network 210, excluding slave node F1, based on specific rules (such as random selection, round-robin selection, hash selection, etc.). These other slave nodes can include slave node F1 and / or slave node F2.

[0114] Step 7: Other slave nodes determine whether their local transaction pool contains the transaction corresponding to transaction digest 1 based on the request message. If yes, proceed to step 8; otherwise, repeat steps 6 and 7 until the transaction corresponding to transaction digest 1 is obtained.

[0115] Similar to slave node F1, any other slave node, upon receiving a transaction, will also associate and store the transaction and its transaction digest in its local transaction pool. Therefore, the transaction pool of any other slave node contains one or more transactions received by that slave node, along with their corresponding transaction digests. Then, other slave nodes can determine whether their local transaction pool contains the transaction corresponding to transaction digest 1 based on transaction digest 1 carried in the request message. The specific implementation process is similar to step ① above, where "how slave node F1 determines whether its local transaction pool contains the transaction corresponding to transaction digest 1 based on transaction digest 1" is described. For simplicity, it will not be elaborated further here.

[0116] Step 8: Other slave nodes send the transaction corresponding to transaction digest 1 to slave node F1. Accordingly, slave node F1 receives the transaction corresponding to transaction digest 1.

[0117] It is understandable that through steps ③ to ⑧ above, even if the transaction corresponding to transaction digest 1 is missing from slave node F1, slave node F1 can still obtain the transaction corresponding to transaction digest 1, avoiding the impact on consensus of the transaction due to the missing transaction. In addition, when slave node F1 receives the transaction corresponding to transaction digest 1 sent by master node L or other slave nodes, slave node F1 can also store transaction digest 1 and its corresponding transaction association in the local transaction pool.

[0118] It should be noted that although the above only describes how slave node F1 generates the second block based on the first block, the process by which other slave nodes in consensus network 210 (including slave nodes F2 and F3) generate the second block based on the first block is similar to the process by which slave node F1 generates the second block based on the first block. Therefore, the process by which other slave nodes in consensus network 210 generate the second block based on the first block can be referred to steps ① to ⑧ above. For the sake of brevity, it will not be described in detail here.

[0119] In step 308, each slave node in the consensus network 210 verifies the second block and reaches a consensus with the master node L on the legality of the second block.

[0120] Taking slave node F1 as an example, the process of each slave node in consensus network 210 verifying the second block is described. Specifically, slave node F1 can verify the second block from one or more of the following aspects:

[0121] ① Verify the block structure of the second block. Specifically, it is necessary to verify whether the block format of the second block meets the requirements (such as whether it contains a block header, block body, transaction list, etc.), whether the size of the second block is within the maximum allowed range, and whether the fields contained in the block header of the second block (such as timestamp, hash value of the second block, hash value of the previous block of the second block, etc.) are complete and meet the requirements, etc. This application does not limit the scope of verification.

[0122] ② Verify the legality of transactions in the second block. Specifically, it is necessary to verify one or more of the following: whether the format of each transaction in the second block meets the requirements, whether the transaction signature is valid, whether the transaction source exists, whether the transaction output exists, and whether the transaction complies with the rules of the blockchain. This application does not limit the scope of verification.

[0123] ③ Verify the consistency between the second block and the blockchain. Specifically, it is necessary to verify whether the hash value of the previous block in the block header of the second block is consistent with the hash value of the latest block in the local blockchain, whether the timestamp in the block header of the second block conforms to the time order of the blockchain, and whether the transactions in the second block conform to the state rules of the blockchain, etc. This application does not limit the scope of verification.

[0124] ④ Verify whether the second block was received from node F1 through a legitimate network propagation mechanism.

[0125] ⑤ Verify whether the second block conforms to the consensus rules according to the master consensus algorithm used in the consensus network 210, such as verifying whether the second block was proposed by the master node specified by the master consensus algorithm.

[0126] It should be noted that the above content only lists a few possible verification items as examples. In practical applications, the second block can also be verified from other aspects based on business needs, and this application does not limit this. In addition, the verification process of the second block by other slave nodes (including slave nodes F2 and F3) in the consensus network 210 is similar to the verification process of the second block by slave node F1. For the sake of brevity, it will not be described in detail here.

[0127] Once each slave node in consensus network 210 has verified the second block, they will reach a consensus on the second block based on the master-based consensus algorithm. It is understandable that the process by which consensus nodes in consensus network 210 reach a consensus on the legitimacy of the second block may differ depending on the master-based consensus algorithm used. For ease of understanding, two specific examples are provided below.

[0128] Example ①: The consensus network 210 uses the PBFT algorithm as its master consensus algorithm.

[0129] After node F1 verifies the second block, if the second block passes node F1's verification, node F1 will send a first notification message to the other consensus nodes in consensus network 210 (including master node L, slave node F2, and slave node F3) to indicate that the second block has passed node F1's verification. Conversely, if the second block fails node F1's verification, node F1 will not send a first notification message to the other consensus nodes in consensus network 210. Similarly, after node F2 verifies the second block, if it is determined that the second block has passed node F2's verification, node F2 will also send a first notification message to the other consensus nodes in consensus network 210 (including master node L, slave node F1, and slave node F3) to indicate that the second block has passed node F2's verification. Conversely, if the second block fails node F2's verification, node F2 will not send a first notification message to the other consensus nodes in consensus network 210. After node F3 verifies the second block, if it determines that the second block has passed the verification by node F3, then node F3 will send a first notification message to the other consensus nodes in consensus network 210 (including master node L, slave node F1, and slave node F2) to indicate that the second block has passed the verification by node F3. Conversely, if the second block has not passed the verification by node F3, then node F3 will not send a first notification message to the other consensus nodes in consensus network 210.

[0130] When master node L receives a first notification message exceeding the second threshold, it sends a second notification message to slave nodes F1, F2, and F3 respectively, indicating its approval of the legitimacy of the second block. This second threshold is typically greater than or equal to two-thirds of the total number of consensus nodes in the consensus network 210. Similarly, when slave node F1 receives a first notification message exceeding the second threshold, it sends a second notification message to master node L, F2, and F3 respectively, indicating its approval of the second block. When slave node F2 receives a first notification message exceeding the second threshold, it sends a second notification message to master node L, F1, and F3 respectively, indicating its approval of the second block. When slave node F3 receives a first notification message exceeding the second threshold, it sends a second notification message to master node L, F1, and F2 respectively, indicating its approval of the second block.

[0131] When master node L receives a second notification message exceeding the second threshold, master node L determines that a sufficient number of consensus nodes recognize the legitimacy of the second block, and thus confirms the second block as legitimate. Similarly, when slave node F1 receives a second notification message exceeding the second threshold, slave node F1 determines that a sufficient number of consensus nodes recognize the legitimacy of the second block, and thus confirms the second block as legitimate. When slave node F2 receives a second notification message exceeding the second threshold, slave node F2 determines that a sufficient number of consensus nodes recognize the legitimacy of the second block, and thus confirms the second block as legitimate. When slave node F3 receives a second notification message exceeding the second threshold, slave node F3 determines that a sufficient number of consensus nodes recognize the legitimacy of the second block, and thus confirms the second block as legitimate. Therefore, master node L, slave nodes F1, F2, and F3 reach a consensus on the legitimacy of the second block.

[0132] Example ②: The consensus network 210 uses the Raft algorithm as its master consensus algorithm.

[0133] After node F1 verifies the second block, if the second block passes the verification by node F1, node F1 will send a third notification message to the master node L to indicate that the second block has passed the verification by node F1. Conversely, if the second block fails the verification by node F1, node F1 will not send a third notification message to the master node L.

[0134] Similarly, after slave node F2 verifies the second block, if it determines that the second block has passed its verification, slave node F2 will also send a third notification message to master node L to indicate that the second block has passed its verification. Conversely, if the second block has not passed its verification, slave node F2 will not send a third notification message to master node L. After slave node F3 verifies the second block, if it determines that the second block has passed its verification, slave node F3 will send a third notification message to master node L to indicate that the second block has passed its verification. Conversely, if the second block has not passed its verification, slave node F3 will not send a third notification message to other consensus nodes in consensus network 210.

[0135] When master node L receives a third notification message exceeding the third threshold (which is typically greater than or equal to half the total number of consensus nodes in consensus network 210), master node L determines that a majority of consensus nodes in consensus network 210 have reached a consensus on the legitimacy of the second block. Subsequently, master node L sends a fourth notification message to slave nodes F1, F2, and F3 respectively, informing them that a majority of consensus nodes in consensus network 210 have reached a consensus on the legitimacy of the second block. Accordingly, slave nodes F1, F2, and F3, upon receiving the fourth notification message, confirm the legitimacy of the second block.

[0136] It is understood that the above examples are only two master-based consensus algorithms that the consensus network 210 may adopt. In practical applications, the consensus network 210 may also adopt other master-based consensus algorithms. Correspondingly, the process by which consensus nodes in the consensus network 210 reach a consensus on the legitimacy of the second block may also be different. This application will not elaborate on these in detail.

[0137] Furthermore, after each consensus node in consensus network 210 determines that the second block is legitimate, it will add the second block to the local blockchain and delete the transactions contained in the second block from the local transaction pool, thus saving storage space in the local transaction pool.

[0138] In addition, each consensus node in consensus network 210 will send a second block to some or all of the non-consensus nodes in its blockchain node cluster. When a consensus node sends the second block only to some of the non-consensus nodes in its cluster, these receiving non-consensus nodes will then send the second block to another group of non-consensus nodes, ensuring that all non-consensus nodes in the cluster receive the second block. Here, non-consensus nodes refer to blockchain nodes other than the consensus node. Each non-consensus node that receives the second block will verify it. After successful verification, it will add the second block to its local blockchain. The verification process for the second block by non-consensus nodes is similar to that by consensus nodes, and for simplicity, it will not be elaborated further here. After adding the second block to their local blockchain, each blockchain node will send a transaction upload message to the corresponding client 100 to inform the client 100 that the transaction information has been stored on the blockchain.

[0139] As can be seen from the descriptions of steps 301 to 308 above, the transaction consensus method provided in this application has the following advantages:

[0140] First, client 100 will send transactions requiring consensus to all consensus nodes in consensus network 210, instead of only sending them to master node L in consensus network 210, and then master node L will broadcast them to other slave nodes. In other words, the technical solution provided in this application can transfer the bandwidth load of master node L to client 100, reduce the bandwidth load of master node L, and improve the consensus performance of consensus network 210.

[0141] Secondly, the first block sent by the master node L to each slave node consists of a transaction digest. The size of the transaction digest is usually smaller than the size of the transaction itself, which further reduces the bandwidth load of the master node L.

[0142] Third, the transaction consensus method provided in this application is simple to implement and does not limit the master consensus algorithm adopted by the consensus network 210, thus having strong applicability.

[0143] The transaction consensus method provided in this application has been described in detail above with reference to Figures 1 to 3. The transaction consensus system provided in this application will be described below with reference to Figure 4.

[0144] Referring to Figure 4, Figure 4 exemplarily illustrates a schematic diagram of the structure of a transaction consensus system. As shown in Figure 4, the transaction consensus system 400 includes a consensus network 410 and one or more clients 420 connected to the consensus network 410 via a network (such as a wide area network or a local area network). Figure 4 illustrates an example where the transaction consensus system 400 includes multiple clients 420.

[0145] The consensus network 410 includes a master node 411 and multiple slave nodes 412. The master node 411 executes the steps performed by the master node L in the aforementioned transaction consensus method, and the slave nodes 412 execute the steps performed by the slave nodes in the same method. The client 420 executes the steps performed by the client 100 in the same transaction consensus method. It is worth noting that the client 420 in the transaction consensus system 400 refers to the client of the consensus network 410, which sends transactions to be consensused to the consensus network 410. Specifically, the client 420 can be either client 100 or other devices sending transactions to be consensused to the consensus network 410, such as the blockchain node mentioned in step 301 that endorses transaction 1. In this case, after endorsing transaction 1, the blockchain node can directly assemble transaction 1 and its endorsement result and send the assembly result to the master node 411 and multiple slave nodes 412 in the consensus network 410.

[0146] Specifically, client 420 sends a transaction to master node 411 and multiple slave nodes 412 in consensus network 410. After successfully receiving the transaction from client 420, master node 411 or slave node 412 generates a corresponding transaction digest. Slave node 412 also sends the generated transaction digest to master node 411. Master node 411 determines the reception status of the transaction sent by client 420 based on the transaction digests sent by each slave node 412, and generates a block based on the reception status. Master node 411 also verifies the block; if the verification is successful, it sends the block to all slave nodes 412 in consensus network 410. After receiving the block, slave nodes 412 construct a new block based on it, verify the new block, and thus reach a consensus with master node 411 on the legality of the new block.

[0147] It is understood that the specific details of any possible implementation of the relevant steps performed by each part of the transaction consensus system 400 (i.e., master node 411, slave node 412 and client 420) can be referred to the relevant content of the foregoing method embodiments, and will not be repeated here.

[0148] The master node 411, slave node 412, and client 420 can be implemented in software or hardware. For example, the implementation of the master node 411 will be described below. Similarly, the implementation of the slave node 412 and client 420 can refer to the implementation of the master node 411.

[0149] As an example of a software functional unit, master node 411 may include code running on a compute instance. The compute instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned compute instance may be one or more. For example, master node 411 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0150] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0151] As an example of a hardware functional unit, the master node 411 may include at least one computing device, such as a server. The master node 411 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The aforementioned PLD can be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0152] The multiple computing devices included in master node 411 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in master node 411 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in master node 411 can be distributed in the same VPC or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0153] This application also provides a computing device cluster. The computing device cluster includes at least one computing device, which may be a server, such as a central server or edge server in a cloud data center, or a local server in a local data center. In some embodiments, the computing device in the computing device cluster may also be a terminal device such as a desktop computer, laptop computer, or smartphone.

[0154] Referring to Figure 5, Figure 5 exemplarily illustrates a schematic diagram of a computing device cluster. As shown in Figure 5, the computing device cluster includes at least one computing device 500. The computing device 500 includes a bus 510, a communication interface 520, a processor 530, and a memory 540, wherein the communication interface 520, the processor 530, and the memory 540 communicate with each other via the bus 510. It should be understood that this application does not limit the number of processors 530 and memory 540 in the computing device 500; that is, the computing device 500 may include one or more processors 530 and one or more memories 540, but for ease of description, Figure 5 only shows one processor 530 and one memory 540. The various parts of the computing device 500 will be described in detail below.

[0155] Bus 510 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one line is used in Figure 5, but this does not mean that the computing device 500 has only one bus or one type of bus. Bus 510 can include pathways for transmitting information between various components of the computing device 500 (e.g., communication interface 520, processor 530, and memory 540).

[0156] The communication interface 520 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 500 and other devices or communication networks.

[0157] The processor 530 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0158] Memory 540 may include volatile memory, such as random access memory (RAM). Memory 540 may also include non-volatile memory, such as flash memory, read-only memory (ROM), hard disk drive (HDD), or solid state drive (SSD).

[0159] The memory 540 stores executable code. The processor 530 executes the code stored in the memory 540 to implement the functions of the master node 411, slave node 412, or client 420. That is, the memory 540 stores instructions for implementing the functions of the master node 411, slave node 412, or client 420.

[0160] The memory 540 of one or more computing devices 500 in the computing device cluster may respectively store instructions for implementing some of the functions of the transaction consensus system 400. In other words, the combination of one or more computing devices 500 in the computing device cluster can jointly implement all the functions of the transaction consensus system 400.

[0161] It should be noted that the memory 540 of different computing devices 500 in the computing device cluster can store different instructions, which are used to implement some functions of the transaction consensus system 400. That is to say, the instructions stored in the memory 540 of different computing devices 500 can implement one or more functions of the master node 411, slave node 412 and client 420.

[0162] In some possible implementations, one or more computing devices 500 in a computing device cluster can be connected via a network, which can be a wide area network (WAN) or a local area network (LAN). Figure 6 illustrates one possible implementation. As shown in Figure 6, computing devices 500A, 500B, 500C, and 500D are connected via a network. Specifically, they are connected to the network through communication interfaces in computing devices 500A, 500B, 500C, and 500D. In this implementation, the memory 540 in computing device 500A stores instructions for implementing the functions of the master node 411; the memories 540 in computing devices 500B and 500C store instructions for implementing the functions of the slave node 412; and the memory 540 in computing device 500C stores instructions for implementing the functions of the client 420.

[0163] It is understandable that the functions of computing devices 500A, 500B, 500C, and 500D can all be performed by multiple computing devices 500.

[0164] It should also be understood that the computing device cluster provided in this application corresponds to the transaction consensus system 400 described above, and the functions of each component in the computing device cluster are to implement the corresponding processes of each step in the method shown in Figure 3. For the sake of brevity, these will not be elaborated here.

[0165] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions that can run on a computing device or be stored on any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the transaction consensus method described above.

[0166] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives), etc. The computer-readable storage medium includes instructions that instruct a cluster of computing devices to execute the transaction consensus method described above.

[0167] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A transaction consensus method, characterized in that, A blockchain network includes multiple blockchain nodes, and the consensus network in the blockchain network is composed of some or all of the multiple blockchain nodes. The blockchain nodes in the consensus network include one master node and multiple slave nodes. The method includes: The client sends the target transaction to the master node and the plurality of slave nodes; The first slave node among the plurality of slave nodes generates a transaction summary of the target transaction based on the target transaction, and sends the transaction summary of the target transaction to the master node; The master node sends a transaction summary of the target transaction to the plurality of slave nodes; The second slave node among the plurality of slave nodes, based on the transaction digest of the target transaction, reaches a consensus with the master node and other slave nodes in the consensus network on the target transaction to determine the legality of the target transaction.

2. The method according to claim 1, characterized in that, Before the master node sends the transaction digest of the target transaction to the plurality of slave nodes, the method further includes: The master node determines that the number of blockchain nodes in the consensus network that have received the target transaction is greater than a threshold.

3. The method according to claim 2, characterized in that, The method further includes adjusting the threshold based on the transactions per second (TPS) processed by the consensus network.

4. The method according to any one of claims 1 to 3, characterized in that, The second slave node among the plurality of slave nodes, based on the transaction digest of the target transaction, reaches consensus on the target transaction with the master node and other slave nodes in the consensus network, including: The second slave node obtains the target transaction based on the transaction summary of the target transaction; The second slave node, together with the master node and other slave nodes in the consensus network, reaches a consensus on the target transaction.

5. The method according to claim 4, characterized in that, The second slave node obtains the target transaction based on the transaction digest of the target transaction, including: The second slave node obtains the target transaction from its local transaction pool based on the transaction digest of the target transaction. The transaction pool of the second slave node includes transactions received by the second slave node from the client and their corresponding transaction digests.

6. The method according to claim 4, characterized in that, The second slave node obtains the target transaction based on the transaction digest of the target transaction, including: The second slave node requests the target transaction from the master node or other slave nodes in the consensus network based on the transaction digest of the target transaction, in order to obtain the target transaction.

7. The method according to any one of claims 1 to 6, characterized in that, The blockchain network can be a public blockchain, a private blockchain, or a consortium blockchain.

8. A transaction consensus system, characterized in that, The blockchain network includes multiple blockchain nodes, and the transaction consensus system includes a client and a consensus network. The consensus network is composed of some or all of the multiple blockchain nodes, and the blockchain nodes in the consensus network include one master node and multiple slave nodes. The client is used to send the target transaction to the master node and the plurality of slave nodes; The first slave node among the plurality of slave nodes is configured to generate a transaction summary of the target transaction based on the target transaction, and send the transaction summary of the target transaction to the master node; The master node is used to send a transaction summary of the target transaction to the plurality of slave nodes; The second slave node among the plurality of slave nodes is used to reach a consensus on the target transaction with the master node and other slave nodes in the consensus network based on the transaction digest of the target transaction, so as to determine the legality of the target transaction.

9. The system according to claim 8, characterized in that, The master node is also used to determine that the number of blockchain nodes in the consensus network that have received the target transaction is greater than a threshold.

10. The system according to claim 9, characterized in that, The master node is also used to adjust the threshold based on the transactions per second (TPS) processed by the consensus network.

11. The method according to any one of claims 8 to 10, characterized in that, The second slave node is used to obtain the target transaction based on the transaction digest of the target transaction, and to reach a consensus on the target transaction with the master node and other slave nodes in the consensus network.

12. The system according to claim 11, characterized in that, The second slave node is used to obtain the target transaction from the local transaction pool according to the transaction digest of the target transaction, wherein the transaction pool of the second slave node includes the transactions received by the second slave node from the client and the corresponding transaction digests.

13. The system according to claim 12, characterized in that, The second slave node is used to request the target transaction from the master node or other slave nodes in the consensus network based on the transaction digest of the target transaction, so as to obtain the target transaction.

14. The system according to any one of claims 8 to 13, characterized in that, The blockchain network can be a public blockchain, a private blockchain, or a consortium blockchain.

15. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 7.

16. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1 to 7.

17. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1 to 7.

Images