Blockchain consensus method, system, and cluster of computing devices
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-07
- Publication Date
- 2026-08-11
AI Technical Summary
[0004]但是，上述利用BFT共识算法会随着节点的增多而大幅降低
[0023] In this scheme, the introduction of a supervisory node during the execution of the Raft protocol enables the Raft protocol to resist Byzantine nodes, thereby improving the security and reliability of the system while maintaining consensus efficiency within shards.
Smart Images
Figure CN118200107B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and in particular to a blockchain consensus method, system, and computing device cluster. Background Technology
[0002] Blockchain is a distributed ledger technology, which can also be viewed as a data structure that stores data in chronological order. The consensus mechanism, as the core technology of blockchain, refers to the process of verifying and confirming transactions in a very short time through voting by specific nodes in the blockchain consensus system. If several nodes with unrelated interests can reach a consensus on a transaction, it can be assumed that the entire network can also reach a consensus on it. The purpose of the consensus mechanism is to ensure that all honest nodes maintain a consistent view of the blockchain, which requires simultaneously satisfying two properties: 1) Consistency: The prefix portion of the blockchain maintained by all honest nodes is exactly the same; 2) Validity: Information published by an honest node will eventually be recorded in the blocks of all other honest nodes.
[0003] BFT (Byzantine Fault Tolerance) is a consensus algorithm. Currently, existing blockchain platforms based on the BFT consensus algorithm generally generate blocks through a three-phase commit: Phase 1: Using the BFT consensus algorithm, transactions submitted to the platform reach consensus, and transactions that reach consensus are placed into an ordered queue of confirmed transactions. Phase 2: Block-producing nodes sequentially package transactions from the queue of confirmed transactions into blocks, then broadcast the packaged block to all ledger nodes. Upon receiving the block, the ledger nodes verify the validity of the transactions within the block and return a signature confirmation. Phase 3: After receiving signature confirmations from more than half of the ledger nodes, the block-producing node broadcasts the signature result to all ledger nodes, and the ledger nodes write the block into their own chains.
[0004] However, the aforementioned BFT consensus algorithm suffers a significant decrease as the number of nodes increases.
[0005] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention
[0006] This application provides a blockchain consensus method, system, and computing device cluster. In cross-shard consensus, considering the supervision results of supervisory nodes on the consensus within shards can ensure the security of the consensus process.
[0007] In a first aspect, embodiments of this application provide a blockchain consensus method applied to a blockchain consensus system. The blockchain consensus system includes multiple nodes, which are divided into sorting nodes and multiple shards. The method includes:
[0008] Each of the plurality of shards is divided into a leader node and a plurality of follower nodes; wherein at least one of the plurality of follower nodes also serves as a supervisor node.
[0009] The sorting node determines a first message based on the received request sent by the client; wherein the first message includes a proposal and a proposal number;
[0010] The sorting node sends the first message to the leader node of the plurality of shards;
[0011] In each of the plurality of shards, the leader node and a plurality of follower nodes of the shard execute a first round of consensus protocol based on the first message; wherein, during the execution of the first round of consensus protocol, the supervisor node determines the supervisory result of the leader node of its shard; the supervisory result indicates whether the proposal sent by the leader node of its shard is consistent with the proposal under the proposal number determined by the sorting node;
[0012] The sorting node determines the supervision results of the multiple shards based on the supervision results of the leader node sent by the supervision nodes in the multiple shards;
[0013] After multiple first shards reach consensus by executing the first round of consensus protocol, the leader nodes of the multiple first shards execute the second round of consensus protocol based on the first message and the supervision results of the multiple shards obtained from the sorting nodes; the multiple first shards are at least a part of the multiple shards;
[0014] After the leader node of any of the plurality of first shards executes the second round of consensus protocol and reaches consensus, it submits the proposal.
[0015] In this scheme, on the one hand, a stable arrangement of nodes is used to provide a stable sorting result, avoiding the failure of the overall consensus due to the failure of the view V in the Byzantine fault-tolerant algorithm. On the other hand, by introducing the supervision results of supervisory nodes in the consensus process of leader nodes and follower nodes, the supervision results are used in the consensus between leaders of shards, which improves the security and reliability of the consensus. Furthermore, by adopting the consensus method within shards and the leader node consensus between shards, it is not necessary for all nodes to communicate, which can reduce the complexity of communication and improve the consensus efficiency.
[0016] In one possible implementation, the supervisor node is used to supervise some or all of the leader nodes in the plurality of shards.
[0017] In one possible implementation, the leader node of the plurality of shards obtains the supervision results of the plurality of shards from the sorting node. If the number of shards with normal consensus in the supervision results of the plurality of shards does not meet a preset threshold, consensus fails.
[0018] In this scheme, if the consensus of multiple shards is abnormal, the consensus will not pass, thus ensuring the security of the consensus to a certain extent.
[0019] In one possible implementation, if the leader node of any of the plurality of first shards obtains the supervision result of its shard from the sorting node and finds the consensus abnormal, it will not execute the second round of consensus protocol.
[0020] In this scheme, if the consensus of a shard is abnormal, the leader node of the shard will not execute the second round of consensus protocol. On the one hand, this can ensure the security of the consensus to a certain extent. On the other hand, the number of leader nodes executing the second round of consensus protocol is reduced, which can improve the efficiency of consensus to a certain extent.
[0021] In one possible implementation, the first round of consensus protocol is a protocol without tolerance for malicious behavior.
[0022] In one example, the first round of consensus protocol is the Raft protocol.
[0023] In this scheme, the introduction of a supervisory node during the execution of the Raft protocol enables the Raft protocol to resist Byzantine nodes, thereby improving the security and reliability of the system while maintaining consensus efficiency within shards.
[0024] In one possible implementation, the second round consensus protocol is a Byzantine fault-tolerant protocol, the sorting node is the node that proposes a proposal in the Byzantine fault-tolerant protocol, and the first message is a message generated by the sorting node for executing the second round consensus protocol.
[0025] Secondly, embodiments of this application provide a blockchain consensus system, including multiple nodes, wherein the multiple nodes are divided into sorting nodes and multiple shards;
[0026] Each of the plurality of shards is used to divide into a leader node and a plurality of follower nodes; wherein at least one of the plurality of follower nodes also serves as a supervisor node;
[0027] The sorting node is used to determine a first message based on the received request sent by the client; and send the first message to the leader node of the plurality of shards; wherein the first message includes a proposal and a proposal number;
[0028] The leader node of each shard serves as the leader of multiple follower nodes within that shard, executing the first round of consensus protocol based on the first message;
[0029] The supervisory node is used to determine the supervisory result of the leader node of its shard during the first round of consensus protocol, and send the supervisory result of the leader node of its shard to the sorting node; wherein, the supervisory result of the leader node indicates whether the proposal sent by the leader node is consistent with the proposal number determined by the sorting node.
[0030] The sorting node is used to determine the supervision results of the multiple shards based on the supervision results sent by the supervisory nodes in the multiple shards to the leader node of the shard in which it is located.
[0031] After multiple first shards reach consensus by executing the first round of consensus protocol, the leader nodes of the multiple first shards are used to execute the second round of consensus protocol based on the first message and the supervision results of the multiple shards obtained from the sorting nodes; the multiple first shards are at least a part of the multiple shards;
[0032] The leader node of any of the plurality of first shards is used to submit the proposal after reaching consensus through the second round of consensus protocol.
[0033] The beneficial effects of this solution are described above and will not be repeated here.
[0034] In one possible implementation, the supervisor node is used to supervise some or all of the leader nodes in the plurality of shards.
[0035] In one possible implementation, the leader nodes of the plurality of first shards are used to obtain the supervision results of the plurality of shards from the sorting nodes, and when the number of shards with normal consensus is determined to meet a preset threshold based on the supervision results of the plurality of shards, the second round of consensus protocol is executed.
[0036] The beneficial effects of this solution are described above and will not be repeated here.
[0037] In one possible implementation, the leader node of any of the plurality of first shards is determined to have a consensus failure when it obtains the supervision result of its shard from the sorting node, and will not execute the second round of consensus protocol.
[0038] The beneficial effects of this solution are described above and will not be repeated here.
[0039] In one possible implementation, the first round of consensus protocol is a protocol without tolerance for malicious behavior.
[0040] In one example, the first round of consensus protocol is the Raft protocol.
[0041] The beneficial effects of this solution are described above and will not be repeated here.
[0042] In one possible implementation, the second round consensus protocol is a Byzantine fault-tolerant protocol, the sorting node is the node that proposes a proposal in the Byzantine fault-tolerant protocol, and the first message is a message generated by the sorting node for executing the second round consensus protocol.
[0043] Thirdly, embodiments of this application provide a blockchain consensus network, including: at least one memory for storing a program; and at least one processor for executing the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method provided in the first aspect.
[0044] Fourthly, embodiments of this application provide a blockchain consensus network in which a device executes computer program instructions to perform the method provided in the first aspect. For example, the device may be a chip or a processor.
[0045] In one example, the device may include a processor that can be coupled to memory, read instructions from the memory, and execute the methods provided in the first aspect according to those instructions. The memory may be integrated into the chip or processor, or it may be independent of the chip or processor.
[0046] Fifthly, embodiments of this application provide a computing device cluster, including at least one computing device, each computing device including a processor and a 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, such that the computing device cluster performs the method as described in the first aspect.
[0047] In a sixth aspect, embodiments of this application provide a computer storage medium storing instructions that, when executed on a cluster of computing devices, cause the cluster of computing devices to perform the method provided in the first aspect.
[0048] In a seventh aspect, embodiments of this application provide a computer program product containing instructions that, when executed on a cluster of computing devices, cause the cluster of computing devices to perform the method provided in the first aspect. Attached Figure Description
[0049] Figure 1 This is a system architecture diagram of a blockchain consensus system provided in an embodiment of this application;
[0050] Figure 2 This is a flowchart illustrating a blockchain consensus method provided in an embodiment of this application;
[0051] Figure 3 This is a schematic diagram illustrating an example of a blockchain consensus method provided in an embodiment of this application;
[0052] Figure 4 This is a schematic diagram of the PBFT protocol in related technologies;
[0053] Figure 5 This is a schematic diagram illustrating an example of a blockchain consensus method provided in an embodiment of this application;
[0054] Figure 6 This is a schematic diagram of the SBFT protocol in related technologies;
[0055] Figure 7 This is a schematic diagram of the structure of the computing device provided in the embodiments of this application;
[0056] Figure 8 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;
[0057] Figure 9 yes Figure 8 A schematic diagram of an example of a computing device cluster is provided. Detailed Implementation
[0058] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.
[0059] In the description of the embodiments of this application, the words "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.
[0060] In the description of the embodiments in this application, the term "and / or" is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, B existing alone, and A and B existing simultaneously. Furthermore, unless otherwise stated, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple terminals refer to two or more terminals.
[0061] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.
[0062] The most classic consensus problem in distributed systems is the Byzantine Generals Problem, a fundamental problem in point-to-point communication proposed by Lamport et al. in 1982. It studies the problem of achieving consensus in a scenario where a minority of nodes can act maliciously (messages can be forged). Byzantine fault tolerance is a consensus mechanism derived from the Byzantine Generals Problem, aiming to solve the problem of how nodes can reach consensus in an untrusted environment.
[0063] Blockchains can be classified in different ways according to various standards. Based on their deployment method, they can be divided into public chains, private chains, and consortium chains. This invention applies to consortium chains, which are often used within a specific group or organization, falling between public and private chains, and have certain restrictions and requirements on the organizations and units that join. The core consensus algorithm of the consortium chain is PBFT (Practical Byzantine Fault Tolerance), which was optimized based on existing research at the time, reducing the algorithm's complexity to the polynomial level.
[0064] The PBFT consensus protocol has several shortcomings. First, it relies heavily on inter-node communication, resulting in a network complexity of O(N²), and its consensus efficiency decreases significantly with the increase in the number of nodes. Second, when there are too many nodes or significant network latency, the system may fail to reach consensus within the specified time, leading to frequent view switching and potentially even disrupting PBFT's liveness, rendering the consensus mechanism completely ineffective. Third, in PBFT, malicious nodes cannot be detected and removed from the consensus network in a timely manner.
[0065] Based on this, the embodiments of the present invention propose a blockchain consensus method.
[0066] This method employs two phases: intra-shard consensus and cross-shard consensus. In both phases, ordering nodes and supervisory nodes are introduced to ensure the fairness and security of the consensus mechanism. In this embodiment, on one hand, the introduction of supervisory nodes in intra-shard and cross-shard consensus enables the system to resist Byzantine fault tolerance, thus improving security. On the other hand, by introducing the role of supervisory nodes, the system's security and reliability are improved while maintaining intra-shard consensus efficiency. Furthermore, compared to the PBFT algorithm, the blockchain consensus method provided in this application, using intra-shard formulas and cross-shard consensus, offers higher throughput, lower consensus latency, and [missing information]. This is merely a brief description of the method; detailed information is provided below.
[0067] The following section introduces the blockchain consensus systems that may be applied to the blockchain consensus method provided in the embodiments of the present invention. Figure 1 This diagram illustrates an example architecture of a blockchain consensus system provided by an embodiment of the present invention. The embodiments of the present invention provide a blockchain consensus method that can be applied to, for example... Figure 1 The system architecture diagram shown is as follows. Figure 1 As shown, the blockchain consensus system includes multiple nodes 100 that form the blockchain.
[0068] Node 100 can be a terminal, a computer, or a server. In one example, the server involved in this solution can be used to provide cloud services. It can be a server that can establish communication connections with other devices and provide computing and / or storage functions for other devices, or a super terminal. The server involved in this solution can be a hardware server or embedded in a virtualization environment. For example, the server involved in this solution can be a virtual machine running on a hardware server that includes one or more other virtual machines. This embodiment of the invention does not specifically limit the type of computing device.
[0069] Nodes 100 communicate with each other via a network. This network can be wired or wireless. For example, a wired network can be a cable network, fiber optic network, or Digital Data Network (DDN), while a wireless network can be a telecommunications network, intranet, the Internet, Local Area Network (LAN), Wide Area Network (WAN), Wireless Local Area Network (WLAN), Metropolitan Area Network (MAN), Public Service Telephone Network (PSTN), Bluetooth network, ZigBee network, Global System for Mobile Communications (GSM), CDMA (Code Division Multiple Access) network, CPRS (General Packet Radio Service) network, or any combination thereof. Understandably, a network can use any known network communication protocol to enable communication between different client layers and gateways. These network communication protocols can be various wired or wireless communication protocols, such as Ethernet, Universal Serial Bus (USB), FireWire, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), New Radio (NR), Bluetooth, Wireless Fidelity (Wi-Fi), and other communication protocols.
[0070] In this embodiment, multiple nodes 100 are divided into several sorting nodes 110 and multiple shards 120, such as N shards (for ease of description and distinction, N shards 120 are used as an example below). Each shard 120 consists of a leader node 121 and multiple follower nodes 122. Among the multiple follower nodes 122, there is a supervisor node 123. In other words, a node can have two roles: a follower node 122 and a supervisor node 123. The supervisor node 123 is used to supervise the leader node 121 of its shard 120. Some or all of the multiple shards 120 may have the same supervisor node 123, or they may have different supervisor nodes 123. This embodiment does not specifically limit this. It is worth noting that a node can play multiple roles simultaneously. Furthermore, the blockchain consensus system provided in this embodiment is applied to a consortium blockchain, targeting only members of a specific group and a limited number of third parties. Internally, multiple pre-selected nodes are designated as ledger keepers, and the generation of each block is jointly determined by all pre-selected nodes. Correspondingly, supervisory node 123 is usually the node 100 with the higher trust level among N nodes 100. For example, in the scenario where the state regulates banks, the nodes of the state connected to the blockchain consensus system can serve as supervisory nodes 123.
[0071] It should be noted that the introduction of supervisor node 123 is mainly to prevent the leader node 121 in each shard 120 from acting maliciously and disrupting the consistency of the consensus. Therefore, supervisor node 123 always exists as a follower node 122 and does not participate in the election of leader node 121. In order to protect supervisor node 123 and prevent it from being targeted by malicious leader node 121 for fraud, supervisor node 123 needs to maintain anonymity. That is, leader node 121 does not know which follower nodes 122 in shard 120 are supervisor nodes 123.
[0072] To ensure effective monitoring, rule A can be used to determine the number s of monitoring nodes 123 within a shard 120. Rule A: A shard 120 can have two or more monitoring nodes 123; simultaneously, a monitoring node 123 must monitor at least two shards 120. Specifically, assuming there are N shards in total, with one monitoring node 123 assigned to every m shards, the number s of monitoring nodes 123 satisfies the following formula:
[0073]
[0074] Where N%m represents the remainder when N and m are divided.
[0075] For example, assuming there are N = 4 shards, and each supervisor node 123 is responsible for supervising the leader node 121 in m = 3 shards 120, then the number of supervisor nodes 123 is s ≥ 4 / 3 + 1 = 2. Figure 1As shown, supervisor node 123A is responsible for supervising leader node 121 in shards 120A, shard 120B and shard 120C, and supervisor node B is responsible for supervising leader node 121 in shards 120A, shard 120C and shard 123D.
[0076] In practical applications, under the condition that rule A is satisfied, the supervisor node 123 within a shard 120 can be changed. For example, assuming there are 3 follower nodes 122 in a shard 120 that satisfy rule A, and the number of supervisor nodes 123 is s = 2, then the supervisor node 123 can choose any two of the 3 follower nodes 122 as supervisor nodes 123, and then periodically change, reselecting any two as supervisor nodes 123.
[0077] According to a feasible implementation, it can be assumed that each node determines its own shard and the other nodes contained in its shard through initial configuration during startup. Optionally, during system operation, there is a mechanism that causes the number and composition of shards to change, and each node can obtain its own shard through periodic queries or other methods.
[0078] For supervisor nodes 123, the node can determine itself as a supervisor node in advance during configuration or initialization. For example, it can be made aware of its role and the functions it needs to perform through configuration files, environment variables, etc.
[0079] For leader node 121, in one feasible scenario, the node can determine itself as the leader node during pre-configuration or initialization. For example, it can be made aware of its role through configuration files, environment variables, etc. In another feasible scenario, leader node 121 can be selected from follower nodes 122 in shard 120. Optionally, supervisor node 123 does not participate in voting. For example, time is divided into terms of arbitrary length, represented by consecutive numbers. At the start of shard 120, all nodes are follower nodes 122. Follower nodes 122 themselves know whether they are supervisor nodes 123. When a follower node 122 (not a supervisor node 123) does not receive a valid message from leader node 122 or candidate within a specified time, it initiates an election. Follower node 122 increments its term, changes its state to candidate, and votes for itself. It also sends a vote request (RequestVote) to other follower nodes 122 in the shard. If more than half of the follower nodes in the shard agree, supervisor node 123 will not participate in the vote, ends its candidate state, and becomes leader node 122. In this embodiment, leader nodes 121 in the N shards 120 can be continuously generated through elections.
[0080] In this embodiment, the sorting node 110 sorts the requests sent by the client to determine a first proposal; processes the first proposal to determine a first message, which includes the proposal; and sends the first message to the leader node 121 of the N shards 120. Then, the leader node 121 of each of the N shards 120 and its managed multiple follower nodes 122 execute a first round of consensus protocol based on the first message. During the first round of consensus protocol, the supervisory node 123 performs a supervisory operation to supervise the leader node of its shard 120 and determine the supervisory result of the leader node (indicating whether the proposal sent by the leader node to the follower nodes matches the proposal determined by the sorting node). Consistent); the sorting node 110 determines the intra-shard consensus result of each of the N shards 120 based on the supervision results of the leader node 121 sent by the supervisory node 123 of the N shards 120; wherein, the intra-shard consensus result indicates whether the consensus between the leader node 121 of the shard 120 and the multiple follower nodes 122 managed by it is normal; after reaching a consensus, the leader node 121 of the shard 120 and the multiple follower nodes 122 managed by it execute the second round of consensus protocol based on the supervision results of the N shards obtained from the sorting node 110 and the leader node 121 of the other shards 120; after the leader node 121 of the shard 120 and the leader node 121 of the other shards 120 reach a consensus, they submit a proposal.
[0081] In summary, on the one hand, the embodiments of this application provide stable sorting results for the use of stable node arrangement, avoiding the failure of the overall consensus due to the failure of view V in the PBFT algorithm; on the other hand, by introducing the supervision results of the supervisory node in the consensus process of the leader node 121 and the follower node 122, the supervision results are used in the consensus among the leaders 121 of the shard 120, thereby improving the security and reliability of the consensus; furthermore, by adopting the method of intra-shard consensus and inter-shard leader node consensus, it is not necessary for all nodes to communicate, which can reduce the complexity of communication, improve the consensus efficiency, and enable rapid consensus among more nodes without significantly reducing the consensus efficiency due to the increase in the number of nodes.
[0082] Next, based on the blockchain consensus system provided above, a blockchain consensus method provided by this invention will be described in detail. In this embodiment, the second-round consensus protocol mainly adopts the BFT (Byzantine Fault Tolerance) protocol. The following description uses the BFT protocol as an example for the second-round consensus protocol.
[0083] Figure 2 This is a flowchart illustrating the blockchain consensus method provided in an embodiment of this application. Figure 2As shown in the embodiment of this application, the blockchain consensus method mainly consists of four stages: the first stage is the pre-preparation stage of the sorting node 110, the second stage is the first round of consensus protocol, the third stage is the second round of consensus protocol, and the fourth stage is the proposal submission.
[0084] like Figure 2 As shown, the pre-preparation stage provided in this application embodiment includes at least the following steps:
[0085] Step 201: Sorting node 110 determines the proposal based on the received request sent by the client.
[0086] According to one feasible implementation, after receiving a request sent by the client, the sorting node 110 verifies the client signature carried in the request. If the verification is successful, each request is added to a linear queue. The requests in the linear queue are arranged in timestamp order. Then, the sorted requests are packaged into a proposal from the linear queue in order.
[0087] The number can be the number of transaction requests that need to be packaged or the packaging frequency, etc. Here, a proposal can be understood as a block.
[0088] In one example, requests in a linear queue can be packaged based on packaging parameters. These packaging parameters are...
[0089] In one example, the format of the request sent by the client to sorting node 110 is as follows:<REQUEST,o,t,c、sc> Where o represents the specific operation requested, t represents the timestamp appended by the client when making the request, c represents the client identifier, and sc represents the client's signature on the request.
[0090] Correspondingly, sorting node 110 will verify whether the client's signature is correct, and add it to the linear queue after the verification is successful.
[0091] In this context, a proposal can be considered as message m in the BFT protocol. The types of transactions included in a proposal, and their order, are determined by the sorting node 110 during the pre-preparation phase. In practical applications, the blockchain consensus network may receive many requests from one or more clients. The sorting node 110 determines which transactions are packaged and processed by the blockchain consensus system. Even with the same set of transactions, different execution orders can lead to different final results.
[0092] Step 202: Sort node 110 calculates the number and summary of the proposal, determines the proposal number and summary value of the proposal, and stores them.
[0093] According to a feasible implementation method, sorting node 110 numbers the proposals according to the proposal number increasing over time, thus obtaining the proposal number of the proposal.
[0094] According to one feasible implementation, sorting node 110 performs digest calculation based on the request content in the proposal to determine the digest value of the proposal.
[0095] In one example, the digest calculation can be a hash.
[0096] Furthermore, sorting node 110 maintains the correspondence between proposal numbers and digest values locally, facilitating subsequent processes. For example, the relationship between proposal numbers and digest values can be maintained using key-value pairs.
[0097] Step 203: Sort node 110 generates the first message based on the proposal, proposal number, and summary value.
[0098] It is worth noting that BFT is a state machine replication algorithm where all replicas reside in a single view (hereinafter referred to as v). In this embodiment, when performing BFT, it is not necessary to select a master node from multiple nodes 100; the sorted node 110 can be used as the master node.
[0099] Correspondingly, for example, the first message is a pre-prepare message, and the pre-prepare message is...<PRE-PREPARE,v,n,d,m,sign-p> Here, sign-p represents sorting node 110 pairs.<PRE-PREPARE,v,n,d,m> Perform a signature on sorting node 110. Here, v represents the view number, n represents the proposal number, d represents the proposal's digest value, and m represents the proposal itself.
[0100] Step 204: Sort node 110 sends the first message to the leader node 121 of the N shards 120.
[0101] Step 205: Leader node 121 verifies the first message.
[0102] For example, leader node 121, acting as the backup node, primarily performs the following verifications:
[0103] a. Verify that sign-p in the first message is correct.
[0104] b. Has the leader node 121 received n under the same view v?
[0105] c. Whether n in the first message is within the interval [h, H].
[0106] d. Are the message digests of d and m in the first message the same? In practical applications, the leader node 121 will calculate the message digest of m in the first message to obtain message digest d', and then compare d' with d to see if they are the same.
[0107] In addition, if leader node 12 fails to verify, it considers the first message to be an illegal request, discards the first message directly, and will not participate in the second round of consensus protocol.
[0108] Subsequently, after the leader node 121 verifies the first message, it needs to execute the first round of consensus protocol based on the first message and multiple follower nodes 122 in its shard. If the leader node 121 achieves consensus by executing the first round of consensus protocol, it will execute the second round of consensus protocol. If it achieves consensus by executing the second round of consensus protocol, it will submit a proposal.
[0109] First, the first-round consensus protocol will be introduced. In this embodiment, the first-round consensus protocol is the CFT (CrashFault Tolerance, a fault-tolerance technique for non-Byzantine problems) protocol. It should be noted that the CFT protocol has lower communication complexity, thus reducing the communication complexity of the BFT protocol to a certain extent.
[0110] In one optional scenario, the first round protocol is the Raft protocol. For ease of understanding, the Raft protocol will be introduced.
[0111] In the Ratf protocol: First, the leader node 121 enters the first phase and replicates log entries to other nodes in the cluster via the Log Replication (AppendEntries) RPC (Remote Procedure Call) message.
[0112] Next, if leader node 121 receives a majority of "replication successful" responses, it commits the log entry to its state machine and returns success to the client. If leader node 121 does not receive a majority of "replication successful" responses, it returns an error to the client.
[0113] However, in this embodiment, since consensus is still required among the leader nodes 121, if the leader node 121 receives a majority of "replication successful" responses, it will execute a second round of consensus protocol with the leaders 121 of the other N-1 shards 120 out of the N shards 120. Otherwise, the second round of consensus protocol will not be executed.
[0114] It is worth noting that in this embodiment of the application, the leader node 121 needs to be continuously elected through voting. In other words, the node 100 where the leader node 121 is located is not fixed.
[0115] Figure 3 A schematic diagram illustrating the first-round consensus protocol provided in this application embodiment is the Raft protocol, as shown below. Figure 2 and Figure 3 As shown, the method for executing the first round consensus protocol provided in this application embodiment includes at least the following steps:
[0116] Step 206: After the first message is verified, the leader node 121 generates a log replication RPC message; wherein, the log replication RPC message includes the first message and the log index value of the first message.
[0117] In practical applications, after verifying the first message, leader node 121 writes the first message to its local log, creating a log entry. Then, leader node 121 generates a log replication RPC message for that log entry. This log replication RPC message includes the log entry after the first message was written, as well as other additional information such as the log index and term number. The log index is an integer index corresponding to the log entry; it identifies the log entry and is a consecutive, monotonically increasing integer number. The term number can be understood as the term number of the leader node 121 that created this log entry.
[0118] Step 207: Leader node 121 sends log replication RPC messages to multiple follower nodes 122 in its shard.
[0119] Step 208a: Follower node 122 compares the log index value in the log replication RPC message with its own maximum log index value to determine whether to replicate the first message and obtain the first result of whether the replication was successful.
[0120] Specifically, follower node 122 verifies whether the arrangement of its own log entries and that of its leader node 121 in shard 120 before the first message are consistent. If they are consistent, the first message is replicated successfully; otherwise, the first message is discarded and replication fails. It is worth noting that both follower node 122 and leader node 121 record the first message sent by sorting node 110 as log entries. Therefore, if the arrangement of log entries of follower node 122 and its leader node 121 in shard 120 before the first message is consistent, it indicates that the logs are consistent and replication can proceed.
[0121] Step 209a. Follower node 122 sends the first result to leader node 121.
[0122] Step 210b: The leader node 121 determines whether consensus has been reached based on the first results sent by multiple follower nodes 122 in its shard.
[0123] In one feasible implementation, consensus is determined when the number of first successful replication results received by the leader node 121 exceeds a preset threshold.
[0124] For example, the preset threshold can be half the total number of follower nodes 122 in the shard 120 where the leader node 121 is located.
[0125] In another alternative scenario, the first consensus protocol is the Paxos protocol. For ease of understanding, the Paxos protocol will be introduced below.
[0126] In the Paxos protocol, the roles of councilors are first divided into proposers, acceptors, and learners (who can hold multiple roles). Proposers submit proposals, and the proposal information includes the proposal number and the proposed value. After receiving a proposal, acceptors can accept it. If a proposal is accepted by a majority of acceptors, it is said to be chosen. Learners can only "learn" from chosen proposals.
[0127] The Propser has two important properties: Proposal Number N and Proposal V, abbreviated as Proposer(N,V).
[0128] The Acceptor has three important properties: the response proposal number ResN, the accepted proposal number AcceptN, and the received proposal AcceptV, referred to as Acceptor(ResN, AcceptN, AcceptV).
[0129] In the Paxos protocol, consensus is achieved primarily through three phases.
[0130] Phase 1: Prepare
[0131] Proposer: The Proposer generates a globally unique and incrementing proposal number N and sends a Prepare request to all Acceptors. Here, it is not necessary to carry the proposal content, only the proposal number is needed, that is, send Proposer(N, null).
[0132] Acceptor: After receiving a Prepare request, the Acceptor has two possible outcomes:
[0133] If the Acceptor receives the Prepare request for the first time, it sets ResN=N and responds with OK.
[0134] If the Acceptor is not receiving the Prepare request for the first time, then:
[0135] If the requested proposal number N is less than or equal to the previously persisted proposal number ResN, then no response will be given or an error will be returned.
[0136] If the requested proposal number N is greater than the previously persisted proposal number ResN, then update ResN = N and issue a response. The response can have two outcomes: if this Acceptor has not previously accepted a proposal, simply return "ok". Otherwise, if this Acceptor has previously accepted a proposal, it returns "ok" along with the previously accepted proposal number AcceptN and the accepted proposal AcceptV.
[0137] Phase Two: Acceptance Phase
[0138] Proposer: After receiving the response, there are two possibilities:
[0139] If more than half of the responses are "ok", check if there is a proposal in the response. If so, take proposal V as the AcceptV corresponding to the largest AcceptN in the response. If not, V is set by the current Proposer. Finally, send an accept request, which carries proposal V.
[0140] If more than half of the responses "ok" are not received, a new proposal number N is generated, and the process returns to the first phase to initiate a Prepare request.
[0141] Acceptor: After receiving an accept request, the Acceptor will handle two cases:
[0142] If the submitted proposal request N is greater than the previously saved RespN, accept the proposal, set AcceptN=N, AcceptV=V, and reply with "ok".
[0143] If the submitted proposal request N is less than or equal to the previously saved RespN, it will not be accepted, and no response will be given, or an error will be given.
[0144] Proposer: If the Proposer receives more than half of the OKs, then V is selected; otherwise, a Prepare request is re-initiated.
[0145] Phase Three: Learning Phase
[0146] Learner: After the Proposer receives a majority of Acceptors' Accepts, a resolution is formed, and the formed resolution is sent to all Learners.
[0147] In this embodiment of the application, if the Paxos algorithm is used, the leader node 121 within a shard can act as the Proposer, and the multiple follower nodes 122 can be divided into Acceptors and Learners. Thus, both the follower node 122 and the supervisor node 123 can act as Acceptors or Learners. Therefore, in this embodiment of the application, if the leader node 121 and its managed followers 122 lock the proposal, then the second round of consensus protocol is executed with the leaders 121 of the other shards in the N shards 120.
[0148] It is worth noting that the Paxos protocol used in this application embodiment is the Paxos algorithm in the prior art. For specific implementation details, such as the content of the messages sent in each stage, please refer to the relevant description of the Paxos algorithm in the prior art.
[0149] Furthermore, during the execution of the first consensus protocol by following node 122 and leader node 121, supervisor node 123 supervises leader node 121.
[0150] Figure 2 This is a flowchart illustrating the supervision method provided in the embodiments of this application. Figure 2 As shown, the supervision method provided in this application embodiment includes at least the following steps:
[0151] Step 208b: Supervisory node 123 performs digest calculation on the proposal in the log replication RPC message sent by leader node 121 to determine the first digest value corresponding to the leader node.
[0152] In this embodiment of the application, the algorithms used for digest calculation by supervisor node 123 and sorting node 110 are the same. Therefore, for the same proposal, the digest values obtained by supervisor node 123 and sorting node 110 should be the same.
[0153] Step 209b: Supervisory node 123 sends a proposal digest retrieval request to sorting node 110. The proposal digest retrieval request includes the proposal number from the log replication RPC message.
[0154] Step 210b: Sort node 110 determines the second digest value corresponding to the proposal number in the proposal digest retrieval request.
[0155] Step 211b: Sort node 110 sends the second digest value to supervisor node 123.
[0156] Step 212b: Supervisory node 123 performs a consistency comparison between the first summary value and the second summary value to determine the supervision result of the leader node 121 of the partition 120.
[0157] Step 213b: Supervisor node 123 sends the supervision results of the leader node 121 of its shard 120 to sorting node 110.
[0158] If supervisor node 123 supervises multiple leader nodes 121, then supervisor node 123 sends the supervision results of the multiple leader nodes 121 in the multiple shards 120 to sorting node 110.
[0159] Step 214b: Based on the supervision results of the leader node 121 sent by each supervisor node 123, the sorting node 110 determines the supervision results of the leader node 121 of the N shards.
[0160] It is worth noting that when there are multiple supervisory nodes 123 supervising a shard 120, more than half of the supervisory nodes 123 must have normal supervision results for the leader node 121 of the same shard 120 before the supervision result of the leader node 121 of that shard 120 can be determined to be normal.
[0161] Furthermore, the sorting node 110 stores the node identifier, proposal number, and supervision result of each leader node 121 in the N shards 120. For example, the data can be stored in triples, where the triple is [node identifier, proposal number, supervision result].
[0162] Before proceeding with the second round of consensus protocol, in some possible scenarios, the leader node 121 of each shard 120 needs to determine the number of supervision results in the supervision results of the N shards that indicate that the consensus within the shard is normal, and determine whether to execute the second round of consensus protocol based on the number.
[0163] Figure 2 This is a flowchart illustrating the blockchain consensus method provided in the embodiments of this application. Figure 2 As shown, the method for executing the second-round consensus protocol provided in this application embodiment includes at least the following steps:
[0164] Step 215: Leader node 121 sends a supervision result request to sorting node 110; wherein the supervision result request includes the proposal number.
[0165] Step 216: The sorting node 110 responds to the supervision result request and determines the supervision results of N shards 120 for the proposal number.
[0166] Step 217: The leader node 121 determines whether to execute the second round of consensus protocol based on the monitoring results of the N shards 120 for the proposal number. If so, it executes step 218.
[0167] In one example, if the number of monitoring results showing normal consensus within a shard exceeds a preset threshold, the leader node 121 considers the consensus within the shard to be normal and executes the second round of consensus protocol.
[0168] For example, more than half (N / 2) of the monitoring results must be normal before the second round of consensus protocol can be executed.
[0169] In other possible scenarios, the leader node 121 of each shard 120 needs to determine whether the supervision result of its shard 120 indicates that the consensus within the shard is normal. If so, based on the number of supervision results indicating that the consensus within the shard is normal among the N supervision results of each shard, it determines whether to execute the second round of consensus protocol. See steps 215 to 217 for details. If not, the first message is discarded directly.
[0170] In this case, only the leader node 121 in shard 120, whose consensus is normal according to the supervision results, can execute the second round of consensus protocol. On the one hand, this can ensure the security of consensus. On the other hand, it can reduce the number of nodes participating in the second round of consensus protocol to a certain extent, without all leader nodes 121 needing to participate, thereby ensuring the consensus efficiency of the BFT algorithm.
[0171] In some other possible scenarios, if the leader node 121 of each shard 120 determines that no consensus has been reached during the execution of the first round of consensus protocol, it will not execute the second round of consensus protocol.
[0172] Next, the second-round consensus protocol will be introduced. In this embodiment, the second-round consensus protocol is the BFT (Byzantine Fault Tolerance) protocol.
[0173] In one optional scenario, the second-round consensus protocol is the PBFT protocol. For ease of understanding, the PBFT protocol is described in detail in this embodiment.
[0174] PBFT tolerates a number of invalid or malicious nodes of size f. To ensure the normal operation of the entire system, 2f + 1 normal nodes are required, and the total number of nodes in the system is |R| = 3f + 1. That is, the PBFT algorithm can tolerate less than 1 / 3 of an invalid or malicious node. PBFT is a state machine replication algorithm where all replicas reside in a view (hereinafter referred to as v). When executing PBFT, a master node needs to be selected from multiple nodes 100. The master node can be selected through rotation or random selection, and the nodes 100 other than the master node are used as backup nodes. For example, as shown... Figure 4 As shown, the specific process of the PBFT algorithm is as follows:
[0175] The client (c in the diagram) initiates a transaction request to the primary node. During the PRE-PREPARE phase, primary node 0 collects a certain number of transactions awaiting consensus, sorts them, packages them into a message m (also called the original transaction list), and sends a pre-prepare request to backup nodes 1, 2, and 3. The pre-prepare request includes message m. During the PRE-PREPARE phase, after receiving the pre-prepare request, nodes 1, 2, and 3, if they verify the validity of message m, broadcast the hash value of the received message m via a prepare message (the broadcast content generally does not include message m itself, as message m includes several original transaction requests and is generally quite large). Specifically, node 1 propagates the prepare message to nodes 0, 2, and 3; node 2 propagates the prepare message to nodes 0, 1, and 3; and node 3 propagates the prepare message to nodes 0, 1, and 2. Correspondingly, each node also receives prepare messages broadcast by other nodes. Each node adds its own prepared messages (containing the hash value of message m, representing its own approval) and received prepared messages (containing the hash value of message m, representing the approval of other nodes) to its local log. If a node has collected at least a Quorum number of valid pp / p messages from different nodes (including its own pre-prepare and prepared messages, and received prepared messages), it transitions to the prepared state. During the COMMIT phase, each node participating in the consensus sends a commit message to other consensus nodes after entering the prepared state and adds its own commit message to its local log (representing its own approval). Each node also receives commit messages broadcast by other nodes. If a node has collected at least a Quorum number of valid commit messages from different nodes and adds them to its local log (at which point, including its own, there are a total Quorum number), it transitions to the committed state. Then, the node in the committed state outputs message m as the consensus result for this round.
[0176] In this embodiment of the application, if the PBFT algorithm is used, the sorting node 110 is the master node. Since the master node will not change, the view number v in the message will not change, and the leader node 121 in the N shards can be used as a backup node.
[0177] Figure 5 The diagram illustrates the PBFT protocol as the second-round consensus protocol provided in this application embodiment. Figure 2 and Figure 5 As shown, the method for executing the second-round consensus protocol provided in this application embodiment includes at least the following steps:
[0178] Step 218: Based on the first message, leader node 121 generates a second message and sends the second message to the leader nodes 121 of other shards.
[0179] For example, the second message is a prepare message, which includes...<PREPARE,v,n,d,i,sign-i> Where sign-i represents leader node 121 pairs<PREPARE,v,n,d,i> Perform the signature of leader node 121. Here, i represents the number of leader node 121.
[0180] Step 219: Leader node 121 verifies the second message sent by other leader nodes 121. When the number of verified second messages is higher than the first number, it generates a third message based on the first message and sends the third message to the leader nodes 121 of other shards.
[0181] For example, leader node 121, acting as the backup node, primarily performs the following verifications:
[0182] a. Verify that sign-i in the second message is correct.
[0183] b. Has the leader node 121 received n under the same view v?
[0184] c. Whether n in the second message is within the interval [h, H].
[0185] d. Is the d in the second message the same as the d in the first message?
[0186] In addition, if the leader node 12 verifies that the second message is an illegal request, it will discard the second message directly.
[0187] For example, the first number is 2f+1, where f = (n-1) / 2 (rounded down), and n represents the total number of leader nodes 121 of the N shards, which is N.
[0188] For example, the third message is a COMMIT message, which includes...<COMMIT,v,n,d,i,sign-i> The request is in the specified format. `sign-i` indicates that leader node 121...<PREPARE,v,n,d,i> Perform the signature of leader node 121.
[0189] Step 220: Leader node 121 verifies the third messages sent by other leader nodes 121. When the number of verified third messages is higher than the second number, consensus is confirmed.
[0190] For example, leader node 121, acting as a backup node, primarily performs the following verifications:
[0191] a. Verify that sign-i in the third message is correct.
[0192] b. Has the leader node 121 received n under the same view v?
[0193] c. Whether n in the third message is within the interval [h, H].
[0194] d. Are the d in the third message the same as the d in the first message?
[0195] In addition, if the leader node 12 verifies that the third message is an illegal request, it will discard the third message directly.
[0196] For example, the second number is 2f+1.
[0197] Step 221: Leader node 121 submits a proposal.
[0198] In this embodiment of the application, after confirming that the consensus has been reached, the leader node 121 will submit a proposal, that is, execute the requests in the order requested in the proposal to obtain the requested results.
[0199] In the case where the first round of consensus protocol is Raft, the leader node 121 of shard 120 does not directly send a message to notify follower node 122 to commit a specified log entry. This is because the log replication RPC message or heartbeat message from leader node 121 contains the index of the largest log entry that will be committed. Therefore, follower node 122 can know the log commit position information of leader node 121 through the log replication RPC message or heartbeat message. Thus, when follower node 122 receives a heartbeat message from the leader node, or a new log replication RPC message, it will commit this log entry to its state machine.
[0200] In the case where the consensus protocol in the first round is the Paxos protocol, the leader node 121 of shard 120 needs to directly send a message to notify the follower node 122 to submit the specified proposal.
[0201] Furthermore, in practical applications, after the leader node 121 provides a proposal, it also returns a confirmation message to the client. The client determines whether the leader node 121's proposal submission was correct based on the number of confirmation messages received. Here, the confirmation message includes...<REPLY,v,n,i,r,sign-i> r represents the result of the proposal execution. sign-i indicates that leader node 121...<REPLY,v,n,i,r> Perform the signature of leader node 121.
[0202] In one optional scenario, the second-round consensus protocol is the Tendermint protocol. For ease of understanding, the Tendermint protocol will be introduced below.
[0203] For the Tendermint protocol, some nodes are first randomly selected as validators, and then one of these validators is chosen as the proposer node. The proposer node begins listening to and collecting all transactions across the network. After a few minutes, it assembles a new block and broadcasts it to the entire network; this is the proposal block. Once all validator nodes receive this proposal block, they begin reading all the transactions within it and verifying them one by one. If there are no issues, they send a pre-vote message indicating their agreement with the block and casting a positive vote. If they find any illegal transactions in the block, they cast a negative vote. These vote messages are broadcast to all validator nodes, so each validator node both sends a vote message and collects vote messages from others. When the number of collected affirmative votes exceeds 2 / 3, a pre-commit vote message is sent; this is the second phase of voting. During this phase, each node also listens to and collects pre-commit vote messages. When a validator node collects more than 2 / 3 of the pre-commit approval votes, it means that the block has received the majority's unanimous agreement and can be safely written to the local blockchain, appended to the end, thus completing the commit. At the same time, the block height increases by one, the proposer node index also increases by one, and it enters the next round to start proposing new blocks.
[0204] In this embodiment, the sorting node 110 acts as the proposer, and the leader node 121 acts as the validator. The first message is a pre-vote voting message. In this embodiment, the leader node 121 sends the first message (i.e., the pre-vote voting message) to the leader nodes 121 of the other N shards 120, and verifies the first messages sent by the other N shards 120. When the number of verified first messages is higher than a third number, a second message (a pre-commit voting message) is generated based on the first message, and the second message is sent to the other N shards 120. The leader node 121 verifies the first messages sent by the other N shards 120, and when the number of verified first messages is higher than the third number, consensus is confirmed. For example, the third number is 2N / 3; where N represents the total number of leader nodes 121 of the N shards.
[0205] It is worth noting that the Tendermint protocol used in this application embodiment is the Tendermint algorithm in the prior art. For specific implementation details, such as the content of the pre-commit voting message and the pre-vote voting message, please refer to the relevant description of the Tendermint algorithm in the prior art.
[0206] In one alternative scenario, the second-round consensus protocol is a variant of PBFT, such as / SBFT (Simple Byzantine Fault Tolerance) or RBFT (Redundant Byzantine Fault Tolerance). The SBFT protocol will be used as an example below.
[0207] like Figure 6 As shown, the SBFT process is as follows:
[0208] Requesting Node: The client (c in the diagram) initiates a transaction request to the primary node. This illustrates the process of a client initiating a transaction request. In reality, there can be multiple transaction requests, initiated by one or more different clients to the primary. Each transaction request can be sent directly to the primary or forwarded to it through other nodes.
[0209] Pre-prepare phase: After the Primary collects a certain number of transaction requests, it sorts these requests, packages them into a transaction list, places them in a pre-prepare message, and broadcasts the pre-prepare message to other Replicas.
[0210] Sign-share phase: Each replica signs the pre-prepare message with its own private key share from its first group, generates a signature share, and sends a Sign-share message containing the signature share to each C-Collector (one C-Collector in the diagram).
[0211] Full-commit-Proof phase: Each C-Collector collects at least the first threshold number of signature shares from the first group, recovers the first full signature σ, and broadcasts the full-commit-proof containing the first full signature σ to the Replicas.
[0212] Sign-state phase: Each replica that receives a full-commit-proof replica can use the public key of the first group to verify the first complete signature σ. After successful verification, it can submit the transaction list and execute the transactions in sequence. It also signs the execution result (usually the set of states after execution, which can be represented by the hash value of the root node after the state set is organized into a tree structure) with its own private key share from the second group, generating a signature state, and then sending the signature state to each E-Collector.
[0213] Full-execute-proof phase: After each E-Collector collects at least the second threshold number of signature shares from the second group, it recovers the second complete signature π and broadcasts the full-execute-proof containing the complete signature π to the Replicas.
[0214] Upon receiving the full-execute-proof replica, the second complete signature π can be verified using the total public key of the second set.
[0215] Execute-ack: Any E-Collector can also send an execute-ack message to the requesting client.
[0216] In addition, if the client waits for a timeout, it can resend the request to all replicas.
[0217] Since c-collectors and e-collectors collect and combine threshold signatures and propagate result signatures respectively, they can be referred to as collection nodes.
[0218] Compared to PBFT, SBFT only needs to send 1 / 3 of its message count, achieving consensus much faster.
[0219] In this embodiment of the application, if the SBFT algorithm is used, the leader node 121 within shard 120 can act as the Proposer, and the leader nodes 121 of the N shards 120 can be divided into Replica, c-collector, and e-collector. Therefore, in this embodiment of the application, if the leader node 121 receives a full-execute-proof, it will execute the second round of consensus protocol with the leaders 121 of the other shards in the N shards 120.
[0220] It is worth noting that the SBFT protocol used in this application embodiment is the SBFT algorithm in the prior art. For specific implementation details, such as the content of the messages sent in each stage, please refer to the relevant description of the SBFT algorithm in the prior art.
[0221] It should be noted that the embodiments of this application can employ any type of BFT protocol, such as the aforementioned PBFT, Tendermint, and SBFT protocols. These protocols share similar core ideas, differing primarily in consensus efficiency and communication complexity. In practical applications, different types of protocols can be selected based on the specific circumstances. Furthermore, the embodiments of this application can employ any type of CFT protocol, such as the aforementioned Raft and Paxos protocols. These protocols share similar core ideas, differing primarily in consensus efficiency and communication complexity. In practical applications, different types of protocols can be selected based on the specific circumstances. Considering that the communication load of the CFT protocol is lower than that of the BFT protocol, combining the CFT and BFT protocols can, to some extent, reduce the communication load and improve consensus efficiency. In practical applications, such as... Figure 2 As shown and described above, the PBFT protocol and the Raft protocol can be combined to implement the cross-chain consensus method provided in this application embodiment.
[0222] It is worth noting that, since the leader node 121 and multiple follower nodes 122 in each shard 120 will not participate in the second round of consensus protocol if they fail to reach a consensus in the first round, the actual participants in the second round of consensus protocol are not necessarily the leader nodes 121 of all N shards 120, but may only be the leader nodes 121 of some of the N shards 120. Therefore, optionally, the leader node 121 that executes the first round of consensus protocol can be called the first leader node, and all first leader nodes can enter the process of executing the second round of consensus protocol.
[0223] This application also provides a blockchain consensus system, comprising: a sorting node 110 and N shards 120; wherein,
[0224] Each of the N shards 120 is divided into a leader node 121 and a plurality of follower nodes 122, wherein at least one of the plurality of follower nodes also serves as a supervisor node 123.
[0225] The sorting node 110 is used to determine a first message based on a received request sent by a client; send the first message to the leader node of the plurality of shards; wherein the first message includes a proposal and a proposal number; and determine the supervision results of the N shards 120 based on the supervision results of the leader node 121 of the shard 120 sent by the supervisor node 123 during the execution of the first round of consensus protocol.
[0226] For each of the N shards 120, the leader node 121 in the shard 120, together with multiple follower nodes 122 in the shard 120, executes a first round of consensus protocol based on the first message. After reaching consensus through the execution of the first round of consensus protocol, based on the supervision results of the N shards 120 obtained from the sorting node 110, and the leader nodes 121 of some or all of the N shards 120, executes a second round of consensus protocol. After reaching consensus through the execution of the second round of consensus protocol, the proposal is submitted.
[0227] The functions implemented by sorting node 110, leader node 121, follower node 122, and supervisor node 123 can all be implemented in software or hardware. For example, the implementation of sorting node 110 will be described below. Similarly, the implementation of leader node 121, follower node 122, and supervisor node 123 can refer to the implementation of sorting node 110.
[0228] As an example of a software functional unit, a sorting node 110 may include code running on a compute instance. A compute instance may include at least one of a physical host (compute device), a virtual machine, or a container. Further, the aforementioned compute instance may be one or more. For example, sorting node 110 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.
[0229] 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.
[0230] As an example of a hardware functional unit, the sorting node 110 may include at least one computing device, such as a server. Alternatively, the sorting node 110 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.
[0231] The sorting node 110 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the sorting node 110 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the sorting node 110 can be distributed within the same Virtual Private Cloud (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.
[0232] It should be noted that, in other embodiments, the sorting node 110 can be used to execute any step in the blockchain consensus method, the leader node 121 can be used to execute any step in the blockchain consensus method, and the follower node 122 can be used to execute any step in the blockchain consensus method. The steps implemented by the sorting node 110, the leader node 121, and the follower node 122 can be specified as needed. By implementing different steps in the blockchain consensus method through the sorting node 110, the leader node 121, and the follower node 122, the full functionality of the blockchain consensus system can be achieved.
[0233] This application also provides a computing device 700. For example... Figure 7As shown, the computing device 700 includes a bus 702, a processor 704, a memory 706, and a communication interface 708. The processor 704, the memory 706, and the communication interface 708 communicate with each other via the bus 702. The computing device 700 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 700.
[0234] Bus 702 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 illustration, only one line is used in Figure X, but this does not indicate that there is only one bus or one type of bus. Bus 702 can include pathways for transmitting information between various components of computing device 700 (e.g., memory 706, processor 704, communication interface 708).
[0235] Processor 704 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).
[0236] The memory 706 may include volatile memory, such as random access memory (RAM). The processor 704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).
[0237] The memory 706 stores executable program code, which the processor 704 executes to implement the functions of the aforementioned sorting node 110, leader node 121, follower node 122, and supervisor node 123, thereby realizing the blockchain consensus method. In other words, the memory 706 stores instructions for executing the blockchain consensus method.
[0238] The communication interface 708 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 700 and other devices or communication networks.
[0239] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.
[0240] like Figure 8 As shown, the computing device cluster includes at least one computing device 700. The memory 706 of one or more computing devices 700 in the computing device cluster may store the same instructions for executing blockchain consensus methods.
[0241] In some possible implementations, the memory 706 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the blockchain consensus method. In other words, a combination of one or more computing devices 700 can jointly execute instructions for executing the blockchain consensus method.
[0242] It should be noted that the memory 706 in different computing devices 700 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the blockchain consensus system. That is, the instructions stored in the memory 706 of different computing devices 700 can implement the functions of one or more nodes among the sorting node 110, leader node 121, follower node 122, and supervisor node 123.
[0243] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 9 One possible implementation is shown. For example... Figure 9 As shown, the two computing devices 700A, 700B, and 700C are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this possible implementation, the memory 706 in computing device 700A stores instructions for executing the functions of sorting node 110. Meanwhile, the memory 706 in computing device 700B stores instructions for executing the functions of leader node 121 and follower node 122; and the memory 706 in computing device 700C stores instructions for executing the functions of supervisor node 123.
[0244] Figure 9The connection method between the computing device clusters shown can be as follows: Considering that the blockchain consensus method provided in this application requires the sorting node 110 to handle client requests and has a high status, and performance needs to be guaranteed, it is considered that the functions implemented by the sorting node 110 are executed by the computing device 700A. The leader node 121 and follower node 122 in a shard 120 need to communicate with each other. In order to reduce the complexity of communication, the functions implemented by the leader node 121 and follower node 122 can be executed by the computing device 700B. In addition, the supervisor node 123 has a high degree of trust and is generally supervised by a third party in the consortium blockchain. The third party is different from the leader node 121 and follower node 122. Therefore, the functions implemented by the supervisor node 123 can be executed by the computing device 700C.
[0245] It should be understood that Figure 9 The functions of computing device 700A shown can also be performed by multiple computing devices 700. Similarly, the functions of computing devices 700B and 700C can also be performed by multiple computing devices 700.
[0246] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product runs on at least one computing device, it causes the at least one computing device to execute a blockchain consensus method, or a blockchain consensus mechanism.
[0247] 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 available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a blockchain consensus method, or instruct the computing device to execute a blockchain consensus method.
[0248] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0249] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0250] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of the various embodiments of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the specific details described above.
[0251] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.
[0252] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.
[0253] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.
[0254] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.
Claims
1. A blockchain consensus method, characterized in that, Applied to a blockchain consensus system, the blockchain consensus system includes multiple nodes, which are divided into sorting nodes and multiple shards. The method includes: Each of the plurality of shards is divided into a leader node and a plurality of follower nodes; wherein at least one of the plurality of follower nodes also serves as a supervisor node; The sorting node determines a first message based on the received request sent by the client; wherein the first message includes a proposal and a proposal number; The sorting node sends the first message to the leader node of the plurality of shards; In each of the plurality of shards, the leader node and a plurality of follower nodes of the shard execute a first round of consensus protocol based on the first message; wherein, during the execution of the first round of consensus protocol, the supervisor node determines the supervisory result of the leader node of its shard; the supervisory result indicates whether the proposal sent by the leader node of its shard is consistent with the proposal under the proposal number determined by the sorting node; The sorting node determines the supervision results of the multiple shards based on the supervision results of the leader node sent by the supervision nodes in the multiple shards; After multiple first shards reach consensus by executing the first round of consensus protocol, the leader nodes of the multiple first shards execute the second round of consensus protocol based on the first message and the supervision results of the multiple shards obtained from the sorting nodes; the multiple first shards are at least a part of the multiple shards; After the leader node of any of the plurality of first shards executes the second round of consensus protocol and reaches consensus, it submits the proposal.
2. The method according to claim 1, characterized in that, The supervisory node is used to supervise some or all of the leader nodes in the multiple shards.
3. The method according to claim 1, characterized in that, The leader nodes of the multiple shards obtain the supervision results of the multiple shards from the sorting nodes. If the number of shards with normal consensus in the supervision results of the multiple shards does not meet the preset threshold, the consensus fails.
4. The method according to claim 1, characterized in that, The method further includes: The leader nodes of the multiple first shards obtain the supervision results of the multiple shards from the sorting nodes. When the number of shards with normal consensus is determined based on the supervision results of the multiple shards and meets the preset threshold, the second round of consensus protocol is executed.
5. The method according to claim 1, characterized in that, The first round of consensus protocol was an agreement without the ability to tolerate malicious behavior.
6. The method according to claim 5, characterized in that, The first round of consensus protocol was the Raft protocol.
7. The method according to any one of claims 1 to 6, characterized in that, The second round of consensus protocol is the Byzantine Fault Tolerance Protocol, the sorting node is the node that proposes the proposal in the Byzantine Fault Tolerance Protocol, and the first message is a message generated by the sorting node for executing the second round of consensus protocol.
8. A blockchain consensus system, characterized in that, The blockchain consensus system includes multiple nodes, which are divided into sorting nodes and multiple shards; Each of the plurality of shards is used to divide into a leader node and a plurality of follower nodes; wherein at least one of the plurality of follower nodes also serves as a supervisor node; The sorting node is used to determine a first message based on the received request sent by the client; and send the first message to the leader node of the plurality of shards; wherein the first message includes a proposal and a proposal number; The leader node of each shard serves as the leader of multiple follower nodes within that shard, executing the first round of consensus protocol based on the first message; The supervisory node is used to determine the supervisory result of the leader node of its shard during the first round of consensus protocol, and send the supervisory result of the leader node of its shard to the sorting node; wherein, the supervisory result of the leader node indicates whether the proposal sent by the leader node is consistent with the proposal number determined by the sorting node. The sorting node is used to determine the supervision results of the multiple shards based on the supervision results sent by the supervisory nodes in the multiple shards to the leader node of the shard in which it is located. After multiple first shards reach consensus by executing the first round of consensus protocol, the leader nodes of the multiple first shards are used to execute the second round of consensus protocol based on the first message and the supervision results of the multiple shards obtained from the sorting nodes; the multiple first shards are at least a part of the multiple shards; The leader node of any of the plurality of first shards is used to submit the proposal after reaching consensus through the second round of consensus protocol.
9. 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.
10. 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.
11. 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.
Citation Information
Patent Citations
Raft-PBFT-based block chain consensus method
CN114422513A
Block chain system for energy transaction based on V-raft consensus algorithm
CN114745135A