Dormant Consensus Conversion Method for Byzantine Fault Tolerant Protocol

Abstract

The present invention relates to the field of distributed computing technology, and in particular to a dormant consensus conversion method for a Byzantine fault-tolerant protocol. The method comprises the following steps: S1, constructing a dormant consensus conversion unit; S2, constructing a fast synchronous dormant consensus atomic broadcast protocol Koala-1 and a partially synchronous dormant consensus Koala-2 without a stable storage assumption; S3, partially synchronous dormant consistency processing with stable storage: attacking in a dormant model without a stable storage assumption; converting the BFT protocol into a dormant consensus protocol under a stable storage assumption and storing the minimum intermediate consensus parameters; S4, adjusting the quorum of the main protocol based on Koala-2, and modifying the view change protocol to include a timeout arbitration certificate QC mechanism. The present invention proposes a synchronous atomic broadcast protocol called Koala-1 to reduce network latency; designs a specific structure of a partial synchronization model to obtain a secure dormant consensus through a stable storage assumption; and implements a partially fast synchronous dormant consensus without a stable storage.

Description

Technical Field

[0001] The present invention relates to the field of distributed computing technology, and in particular to a dormant consensus conversion method for a Byzantine fault-tolerant protocol. Background Art

[0002] Byzantine fault-tolerant (BFT) state machine replication is a fundamental tool for fault-tolerant distributed computing, allowing a group of nodes to reach consensus in the presence of arbitrary failures. Classic BFT protocols assume that nodes know each other's identities and that non-faulty nodes should always be online. Recently, the dormant consensus model has been introduced. In dormant consensus, a certain number of nodes may unpredictably go offline (dormant) and subsequently come back online (awake). This model, also known as the crash-recovery model in the distributed computing literature, describes a model in which nodes frequently crash and recover. In this model, it is sometimes assumed that each node has a stable storage space (or log) that can be accessed even if the node crashes and subsequently recovers.

[0003] Classification of dormant consensus: Based on the time assumption, consensus protocols can be divided into three types: synchronous, partially synchronous, and asynchronous. In a synchronous network, there is a known upper limit Δ for information transmission and processing. In a partially synchronous network, there is such an upper limit Δ, but the value of Δ is unknown. In an asynchronous network, there is no upper limit. Most of the currently known dormant consensus protocols consider a synchronous network and an unknown participation model. In this case, the nodes do not know the minimum number of awake honest nodes h. a .

[0004] Existing technical solutions include:

[0005] (1) Synchronous Byzantine Agreement. Many classic synchronous Byzantine agreements and Byzantine broadcast protocols aim to reduce the expected delay or optimal delay. In the sleep model, the parallel work of D'Amato and Zanolini aims to achieve lower delay than MMR. This is achieved by introducing a new stable participation assumption, namely that in each time period [t, t+2Δ], the number of honest nodes that remain awake during this period exceeds the number of Byzantine nodes. Other aspects of synchronous sleep consensus have also been studied. For example, Gafni and Losa studied Byzantine agreement that achieves constant delay in the sleep model. Meanwhile, a recent work by D'Amato, Losa and Zanolini studied the asynchronous resilience of synchronous sleep consensus. Their idea is to make the synchronous protocol run safely even in intermittent asynchronous periods.

[0006] (2) Disk-independent crash recovery. In the distributed computing literature, sleep mode is also called crash recovery model. In fact, crash recovery model consensus for crash-tolerant protocols has been widely studied. Most protocols rely on the stable storage assumption. Protocols without the stable storage assumption are also called diskless crash recovery (DCR) model protocols. Aguilera, Chen, and Toueg discussed under what conditions stable storage is necessary. They proposed two consensus protocols using failure detectors, one with stable storage and the other without. Michael, Ports, Sharma, and Szekeres provided a general method to convert protocols in the crash recovery model (with stable storage) to the diskless crash recovery model. Kończak et al. proposed two recovery algorithms for Paxos to make Paxos correct in the DCR model. All of these works consider benign crash failures. In contrast, our Koala-2 protocol can be regarded as the first BFT protocol in the DCR model.

[0007] (3) Consensus under multiple fault types. Some protocols can tolerate both Byzantine faults and crash faults. Backes and Cachin proposed an asynchronous reliable broadcast protocol for systems with n ≥ 3f + 2s + 1 nodes, where s is the maximum number of crashed nodes. UpRight implemented a partially synchronous BFT-SMR protocol with the same constraints. SBFT provides a dual-mode partially synchronous BFT-SMR protocol for n = 3f + 2c + 1 nodes, where c is the number of crashed or slow nodes.

[0008] However, the existing technical solutions still have the following deficiencies:

[0009] (1) The most famous results in the unknown participation model (MMR, CCS2023) achieved a delay of 14Δ, where Δ is the bound of the network delay. The delay is high and there is a lot of room for improvement.

[0010] (2) To date, the only known dormant consensus in the partially synchronous model is proposed in the Ebb-and-Flow protocol and its subsequent work. It is briefly mentioned that traditional BFT protocols such as HotStuff, PBFT, and Streamlet can be used to directly obtain a dormant consensus assuming a global wake-up time (GAT) (after which every honest node will wake up). As with traditional BFT protocols in the partially synchronous model, a system with n nodes can tolerate fails (i.e., n ≥ 3f + n). Unfortunately, the exact construction is not provided.

[0011] (3) The part without stable storage cannot quickly achieve synchronous dormant consensus. In view of this, we propose a dormant consensus conversion method for the Byzantine fault-tolerant protocol. Summary of the Invention

[0012] The purpose of the present invention is to provide a dormant consensus conversion method for a Byzantine fault-tolerant protocol to solve the problems raised in the above background technology.

[0013] To solve the above technical problems, one of the objectives of the present invention is to provide a dormant consensus conversion method for a Byzantine fault-tolerant protocol, comprising the following steps:

[0014] S1. Construct a dormant consensus conversion unit. The system model and component modules of this unit include at least: Byzantine fault tolerance (BFT) protocol, network model and communication channel, dormant model, encryption assumptions, program blocks, Byzantine arbitration and arbitration certificates, and hierarchical proposal election (GPE) protocol.

[0015] S2. Build the fast synchronous dormant consensus atomic broadcast protocol Koala-1 and the partially synchronous dormant consensus Koala-2 without the stable storage assumption, and use a secure synchronous GPE protocol to build the atomic broadcast ABC protocol;

[0016] S3. Partial synchronization dormancy with stable storage: Attack in a dormancy model without the stable storage assumption; convert the BFT protocol into a dormancy consensus protocol under the stable storage assumption and store the minimum intermediate consensus parameters;

[0017] S4. Adjust the quorum of the main protocol based on Koala-2, and modify the view change protocol to include a timeout arbitration certificate QC mechanism; introduce a new recovery protocol to catch up after the dormant node recovers.

[0018] As a further improvement of the present technical solution, in step S1, the system model and component modules of the dormant consensus conversion unit include:

[0019] In a Byzantine Fault Tolerant (BFT) protocol, clients submit transactions (requests) and nodes deliver them. Clients receive a final response to the submitted transaction from the response. In a BFT system consisting of n nodes, at most f nodes can arbitrarily fail under the control of an adversary (i.e., the network scheduler). These failed nodes are also called Byzantine faults, while non-Byzantine nodes are called honest nodes.

[0020] In the network model and communication channels, both synchronous and partially synchronous networks are considered;

[0021] In the sleeping model, sleeping nodes can be awake or asleep; awake nodes actively participate in execution, while sleeping nodes do not execute any code of the protocol and do not send / receive any information;

[0022] In the encryption assumption, digital signatures with public key infrastructure PKI are used;

[0023] In the program block, block B represents a batch of transactions, and the blocks are sorted in the form of a chain;

[0024] In Byzantine arbitration and arbitration certificates, a Byzantine arbitrator (abbreviated as arbitrator) represents a specific number of nodes. To reach a consensus, honest nodes must obtain matching votes from the Byzantine arbitrator. A set of signatures signed by the Byzantine arbitrator is called an arbitration certificate QC (abbreviated as QC or certificate).

[0025] As a further improvement to this technical solution, in step S2, when constructing the atomic broadcast ABC protocol using a secure synchronous GPE protocol, a practical dormant consensus is first established in a known participation model, with a latency close to that of a traditional synchronous BFT protocol. The GPE protocol works as follows:

[0026] Consider each node proposing a block to broadcast; the protocol starts with a round in which each node broadcasts the proposed block, and a leader election mechanism is usually embedded in this round;

[0027] Assuming all honest nodes agree on a common leader, each node will then propagate the blocks it receives from the leader back to all other nodes.

[0028] Once f+1 echo blocks B are received, each node will forward the certificate to all nodes in the third round;

[0029] If a node detects leader ambiguity, it forwards the ambiguous message to all nodes;

[0030] If a valid certificate for B is received in the second round and no ambiguity is detected at the end of the third round, the node will decide on block B with level 1;

[0031] If no ambiguity is detected in the second round, and a valid certificate for B is received at the end of the third round, any undecided node decides on block B with rank 0;

[0032] When a node decides on a block B at level 1, it will deliver block B in the ABC protocol.

[0033] As a further improvement of this technical solution, step S2 includes:

[0034] S2.1 Propose and verify a valid three-level proposal to elect VT-GPE;

[0035] S2.2. Construct the atomic broadcast ABC protocol. This protocol is constructed view by view following the classic BFT protocol and the previous dormant consensus protocol. In each view, each honest node broadcasts a block and transmits at most one block.

[0036] In step S2.1, the three-level proposal election VT-GPE for verification is defined as follows:

[0037] Each honest node proposes a block (and a valid proof) and decides either (B, g, σ) (where B≠⊥) or ⊥, with ⊥ being the winning input; where g is a rank, g∈{0,1,2};

[0038] An external validity property is also needed in order to validate VT-GPE;

[0039] At the same time, define a global predicate, determined by the specific application and known to all parties; define σ as a proof of the validity of block B; let the predicate be Q, if Q(B, σ) holds, then B is verified by σ;

[0040] Each honest node decides only one block in a VT-GPE instance, but it may decide the same block multiple times at different levels;

[0041] Furthermore, a validated VT-GPE protocol can achieve the following properties: external validity, consistency, grade delivery, and effectiveness.

[0042] As a further improvement of the present technical solution, in step S2.2, the operation process of the atomic broadcast ABC protocol includes:

[0043] The agreement is viewed from Figure 1 Start; in each view v, there is a VT-GPE v VT-GPE instance;

[0044] In each VT-GPE v In each node p i Proposes to extend the block B whose candidate is B, where B is node p i Broadcasted blocks; To maintain state, each node maintains several local parameters, including candidates and locks, initially set to the initial block B i ; If a block B is determined with level 0 (or 1), the candidate (or lock) is set to B.

[0045] As a further improvement of this technical solution, in the atomic broadcast ABC protocol, the global predicate Q of VT-GPE is defined as:

[0046] Given any node p j The proposed value (B, qc) is valid at p if and only if the following conditions hold: i Q(B,qc) holds:

[0047] Condition 1: Block view number view(B) is equal to node p i The current view number of B, qc is a valid prepareQC for B, and the parent block of B is qc's block;

[0048] Condition 2: The view number of qc is at least the same as p i The view number of the lock is the same as the view number of the lock.

[0049] As a further improvement of this technical solution, step 3 includes:

[0050] S3.1. Run HotStuff, a threshold signature-based BFT consensus algorithm, on a view-by-view basis, using the syntax of Byzantine Fault Tolerance (BFT). In HotStuff, all nodes agree on a single leader in each view.

[0051] S3.2, attacking HotStuff in a dormant model without the stable storage assumption;

[0052] S3.3, a mature dormant consensus protocol under the stable storage assumption, transforming the traditional BFT protocol into a dormant consensus protocol while storing the minimum intermediate consensus parameters in stable storage;

[0053] In step S3.1, in HotStuff, to reach an agreement on a block, each view includes the following stages:

[0054] Prepare: Leader p k Propose a block B by extending the block with the highest prepareQC received, where prepareQC is the nf received in the “prepare” step of the previous view <prepare>A collection of messages; upon receiving a message from p k If the node has a valid proposal B, it will vote for B. <prepare>Ticket, and send the ticket to p k ; nf <prepare>The set of votes constitutes a qc, denoted as prepareQC;

[0055] Pre-commit: p k After collecting B's prepareQC, it will broadcast the prepareQC to all nodes; after receiving the valid prepareQC of B, the node will vote for B. <pre-commit>Ticket and send it to p k ; Similarly, nf <pre-commit>The collection of tickets constitutes a precommitQC;

[0056] Commit: Once the precommitQC is available, the leader p k will broadcast precommitQC to all nodes; after receiving B's precommitQC, the node will lock B (the node will set the locked arbitration certificate lockedQC to precommitQC); then, each node votes for B. <commit>Ticket, and send the ticket to p k ; nf <commit>The collection of tickets constitutes the certificate commitQC;

[0057] Decision: Once B's commitQC is collected, p k The commitQC will be sent to all nodes, and then each node will deliver block B;

[0058] Enter the next view: Before entering the next view, the node will pass <new-view>The message sends its prepareQC to the next leader (which does not necessarily change in every view).

[0059] As a further improvement of this technical solution, in step S3.2, the attack on HotStuff in the dormant model without the stable storage assumption is specifically as follows:

[0060] First, we assume that in a partially synchronous network, we can assume that there is a network scheduler, i.e., the adversary, during the asynchronous period.

[0061] Furthermore, during the asynchronous period, we consider an adversary (i.e., the network scheduler) manipulating the network, which is the same as the situation assumed by the asynchronous protocol; however, after the global stability time GST, the network becomes synchronized;

[0062] Furthermore, the adversary controls nodes that may enter a sleeping state; in this case, the sleeping nodes are still honest but cannot process any messages while they are sleeping;

[0063] Therefore, it is necessary to attack the dormant nodes at this time to wake them up and ensure the correct operation of the BFT protocol.

[0064] As a further improvement of this technical solution, step S4 includes:

[0065] S4.1. Demonstrate a correct recovery protocol in Koala-2 and modify the view change protocol to complete the conversion of the BFT protocol to a dormant consensus protocol.

[0066] S4.2. Modified view change protocol and recovery protocol: When a timeout occurs under normal circumstances, the modified view change protocol is triggered and the steps of the recovery protocol are executed;

[0067] In step S4.2, the modified view change protocol triggering process is as follows:

[0068] When node p i When a timeout occurs within view v, it stops normal operation and broadcasts<TIMEOUT,v> i information;

[0069] nfs matching from different nodes <timeout>The collection of messages forms a timeout QC;

[0070] After receiving a valid timeout QC for view v, p i Will continue to view v+1;

[0071] To speed up the view changing process, p i You can receive f+1 views of v <timeout>Broadcast after message<TIMEOUT,v> i information;

[0072] When p i When receiving a timeout QC for view v, it forwards the timeout QC to all nodes.

[0073] As a further improvement of this technical solution, in step S4.2, the steps of restoring the protocol include the following:

[0074] S4.2.1. Get timeout QC: Recovered node p i First broadcast <recovery-1>message; upon receiving <recovery-1>After receiving the message, any awake node will send a i Respond to the latest timeout QC (i.e., by <echo-1>message); once nfs valid timeout QC is received, p i The view with the highest number will be selected h ; Then, p i Wait for a timeout QC with view number v ≥ vh+2 before going to the next step;

[0075] S4.2.2, Atomic QC acquisition mechanism: After receiving the timeout QCtc of view number v≥vh+2, p i Set its local timeout QC to tc and broadcast<RECOVERY-2,tc> i message; any awake node that receives this message will first initiate the view change protocol and then proceed to view view(tc)+1; then, the node sends a i Send a<ECHO-2,curView,(prepareQC,lockedQC)> Message, where curView is the current view number; when p i Receive nfs with view number higher than vh+2 <echo-2>message, it sets its own lock's quorum certificate lockedQC to the highest lockedQC in the message, and sets its prepareQC to the highest prepareQC; after that, p i Set the current view number to view(timeoutQC)+1 and become awake.

[0076] Compared with the prior art, the present invention has the following beneficial effects:

[0077] 1. In the dormant consensus transition method of this Byzantine fault-tolerant protocol, a synchronous atomic broadcast protocol called Koala-1 is proposed to reduce network latency. Its expected latency is 5Δ+2δ, and the best-case latency is 2Δ+2δ.

[0078] 2. In the sleep consensus conversion method of this Byzantine fault-tolerant protocol, a specific construction of the partial synchronization model is designed. In a partially synchronous network (where the value of Δ is unknown), without changing the traditional n ≥ 3f + 1 assumption, a secure sleep consensus can only be achieved through the stable storage assumption (where nodes need to store intermediate consensus parameters in stable storage);

[0079] 3. In the dormant consensus transition method of this Byzantine fault-tolerant protocol, in a partially synchronous network, but without assuming stable storage, we can prove the bound of n ≥ 3f + 2s + 1, without considering the global wake-up time (GAT) assumption (all honest nodes wake up after the GAT) and the bound of n ≥ 3f + s + 1, and achieve partially fast synchronous dormant consensus without stable storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] Figure 1 is an exemplary overall method flow chart of the present invention;

[0081] Figure 2 Schematic diagrams of two exemplary cases of the synchronous atomic broadcast protocol in the dormant model in the present invention;

[0082] Figure 3 This is a comparison diagram of exemplary MMR and Koala-1 in the present invention;

[0083] Figure 4 Schematic diagram of an attack on HotStuff in the dormant model assuming that intermediate consensus parameters are not stored in stable storage, as exemplified in the present invention. DETAILED DESCRIPTION

[0084] The following will provide a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0085] Example 1

[0086] like Figures 1-4 As shown, this embodiment provides a dormant consensus conversion method for a Byzantine fault-tolerant protocol, including the following steps:

[0087] S1. Construct a dormant consensus conversion unit. The system model and component modules of this unit include at least: Byzantine fault tolerance (BFT) protocol, network model and communication channel, dormant model, encryption assumptions, program blocks, Byzantine arbitration and arbitration certificates, and hierarchical proposal election (GPE) protocol.

[0088] Specifically, in a Byzantine Fault Tolerance (BFT) protocol, clients submit transactions (requests) and nodes deliver them. The client receives a final response to the submitted transaction from the response. In a BFT system consisting of n nodes, at most f nodes can arbitrarily fail under the control of an adversary (i.e., the network scheduler). These failed nodes are also called Byzantine faults, while non-Byzantine nodes are called honest nodes.

[0089] Among them, the correctness of the BFT protocol (under the dormant model) is stipulated as follows:

[0090] Security: If an honest node delivers tx ′ If the transaction tx was delivered before, then no honest node can deliver the transaction tx without first delivering tx. ′ ;

[0091] Validity: If a transaction tx is submitted to all honest nodes, then all awake honest nodes will eventually deliver tx;

[0092] The equivalent primitive atomic broadcast (ABC) is often used interchangeably with BFT; atomic broadcast differs from BFT only in syntax; in atomic broadcast, one node broadcasts information, and all nodes relay it.

[0093] Security: If an honest node sends m ′ A message m was sent before, so no honest node sends message m without sending m ′ ;

[0094] Validity: If an honest node broadcasts a message m, then all awake honest nodes will eventually pass on the message m.

[0095] Among them, although BFT and atomic broadcast do not expose the order to API, most protocols provide an implicit order; using this implicit order, many partial synchronization protocols achieve the following weaker security properties:

[0096] Consistency: If an honest node delivers transaction tx and another honest node delivers transaction tx′, and the two are in the same order, then tx = tx′.

[0097] In the network model and communication channels, both synchronous and partially synchronous networks are considered. In the synchronous model, there is an upper bound Δ on the information processing and transmission delay. Furthermore, we assume a completely synchronized clock, that is, all nodes have access to a common global clock. In the partially synchronous model, an upper bound still exists, but the value of Δ is unknown. Another concept in the partially synchronous model is the existence of an unknown global settling time (GST), after which information sent between two honest nodes arrives within a fixed delay.

[0098] Furthermore, assuming that the channel for information transmission is authenticated, the symbol * can be used to represent any value; δ represents the actual network delay.

[0099] In the sleeper model (the concept of the sleeper model was first proposed by Pass and Shi), sleeper nodes can be awake or asleep; awake nodes actively participate in the execution, while sleeper nodes do not execute any code of the protocol and do not send or receive any information;

[0100] In this system, every honest node can become dormant, allowing its state to change at any time under the control of an adversary without prior notice. In practice, this means allowing nodes to leave and rejoin the protocol execution at will without notifying other nodes. In the distributed computing literature, the "dormant" model is consistent with the "crash-recovery" model, in which nodes can repeatedly crash and recover. Notably, an honest node may experience "amnesia" after a crash, resulting in the loss of its internal state stored in volatile memory.

[0101] A known participation model is considered, in which all nodes know in advance the minimum number h of awake honest nodes a At the same time, s is used to represent the maximum number of sleeping nodes at any time during the execution of the protocol. In the synchronous sleep consensus protocol, h a is f+1. In the partial synchronization consensus protocol, a is If we consider the global awakening time (GAT) assumption, that is, after the GAT, every sleeping node will be awakened, then our partial synchronization protocol can be achieved: a =2f+1.

[0102] In the encryption assumption, digital signatures with public key infrastructure PK1 are used; using <μ> i To represent the node p i Signed information μ. Assume there is a cryptographic collision-resistant hash function, denoted by H(·).

[0103] A verifiable random function (VRF) is also assumed in one of the protocols. i Evaluate (ρ on any input μ i ,π i )←VRF i (μ) and get a pseudo-random value ρ i and a proof of π i Using Pi i and node p i Anyone can verify the public key of i Is it VRF? i Correct evaluation of the input μ.

[0104] In a program, a batch of transactions is represented by block B, and blocks are ordered in a chain; the block preceding B is called its parent block. The first block in the chain is called genesis block B0. If block B' is an ancestor of block B in the blockchain, then block B extends block B'. ​​If neither block B nor B' extends the other, they conflict.

[0105] In Byzantine arbitration and arbitration certificates, Byzantine arbitration (abbreviated as arbitration) represents a specific number of nodes; to reach a consensus, honest nodes must obtain matching votes from the Byzantine arbitration; a set of signatures signed by the Byzantine arbitration is called an arbitration certificate QC (abbreviated as QC or certificate); in a traditional BFT system with n≥3f+1 nodes, Byzantine arbitration is composed of By slightly abusing notation, we use the view() function to represent the view number of a QC or chunk. For example, if qc is the QC of chunk B, then view(qc) = view(B).

[0106] The GPE protocol is a hierarchical proposal election protocol. The concept of GPE was proposed by MMR. In GPE, each node proposes a block and decides (B, g) or ⊥, where B is a block and g∈{0,1} is the level. GPE has the following characteristics:

[0107] Consistency: If an honest node decides (B, *) and another honest node decides (B′, *), then B = B′;

[0108] Hierarchical delivery: If an honest node decides (B, 1), all honest nodes decide (B, *);

[0109] 1 / 2 valid: With probability at least 1 / 2, all honest nodes decide (B, 1), where B is proposed by an honest node.

[0110] S2. Constructing the fast synchronous dormant consensus atomic broadcast protocol Koala-1 and the partially synchronous dormant consensus Koala-2 without the stable storage assumption, and using a secure synchronous GPE protocol to construct the atomic broadcast ABC protocol: This step introduces a synchronous dormant consensus atomic broadcast protocol called Koala-1. Consider a network with n≥2f+s+1 nodes and h a =f+1. It is assumed that all f faulty nodes are always awake, which is the same assumption made in previous studies. Without loss of generality, it is assumed that storage and message delivery are stable. That is, once a node becomes awake at time t, it immediately receives all messages sent to it by any honest node before time t-Δ. The Koala-1 protocol follows the traditional atomic broadcast model.

[0111] Specifically, we establish a practical dormant consensus in a known participation model with latency approaching that of traditional synchronous BFT protocols. In particular, Koala-1 has a fast path that achieves a latency of 2Δ+26, which occurs when all awake nodes are honest. Meanwhile, Koala-1's expected latency is 5Δ+2δ. In comparison, the state-of-the-art dormant consensus protocol, MMR, has a latency of 14Δ, more than double that of Koala-1. Furthermore, Koala-1 employs a pipelined approach, allowing nodes to begin processing a new block before consensus on the current block is reached.

[0112] Among them, the atomic broadcast ABC protocol is constructed using a secure synchronous GPE protocol;

[0113] In the classic static participation model, we can assume n = 2f + 1 and a quorum size of f + 1 to obtain a synchronous atomic broadcast protocol. Indeed, as mentioned in MMR, f + 1 matching votes form a quorum certificate, and this certificate is transferable, meaning it can be verified by any node. Adding an equivalence detection mechanism to detect whether a node sends inconsistent messages to different nodes, we can obtain a secure synchronous GPE protocol, which can be used to construct the atomic broadcast (ABC) protocol.

[0114] Specifically, the GPE protocol works as follows:

[0115] Consider each node proposing a block to broadcast; the protocol starts with a round in which each node broadcasts the proposed block, and a leader election mechanism is usually embedded in this round;

[0116] Assuming all honest nodes agree on a common leader, each node will then propagate the blocks it receives from the leader back to all other nodes.

[0117] Once f+1 echo blocks B are received, each node will forward the certificate to all nodes in the third round;

[0118] If a node detects leader ambiguity, it forwards the ambiguous message to all nodes;

[0119] If a valid certificate for B is received in the second round and no ambiguity is detected at the end of the third round, the node will decide on block B with level 1;

[0120] If no ambiguity is detected in the second round, and a valid certificate for B is received at the end of the third round, any undecided node decides on block B with rank 0;

[0121] When a node decides on a block B at level 1, it will deliver block B in the ABC protocol.

[0122] Previous synchronous Byzantine agreement and atomic broadcast protocols also roughly follow this paradigm. Here, the ranks are very close to the commit-lock relationship in traditional BFT. In other words, for block B, rank 0 can be considered a lock on B, and honest nodes will never vote for another block that conflicts with B. At the same time, if a node decides on B with rank 1, then the block is committed. In some cases, each node may also need to broadcast its lock block (possibly in another round) to ensure the correctness of the protocol.

[0123] In the sleep model, an attractive solution is to simply change the size of the Byzantine quorum and convert the above-mentioned protocol into a sleep consensus protocol. However, even in the known participation model, building a secure sleep consensus protocol is far from easy. This is mainly because the traditional quorum size can no longer be used as before, because (probably most) honest nodes may enter the sleep state. Without loss of generality, assume n = 2f + s + 1. If we use the traditional method to determine the Byzantine quorum, then the quorum size becomes However, at any moment in the protocol execution, only at least h a = f + 1 honest nodes are awake. Use h a The size of the quorum may easily make the protocol vulnerable to security issues, so it is recommended to have h a The certificate matching the ticket may not be delivered.

[0124] like Figure 2 Figure 2 shows two scenarios of the synchronous atomic broadcast protocol in the sleep model. In both scenarios, p2 is a Byzantine node, and p4 receives B′2 and a valid certificate for B2 from p2. In the first scenario, p1 and p3 submit B2. In contrast, in the second scenario, neither p1 nor p3 submits any blocks.

[0125] in, Figure 2 (a) is scenario 1: p2 sends B2 to p1 and p3, and B′2 to p4. p1 and p3 respond to B2, collect the certificates, and deliver them; Figure 2 (b) is scenario 2: p2 sends B2 to p1 and B′2 to p3 and p4. p1 responds with B2, and p3 responds with B′2. Neither p1 nor p3 submits any blocks.

[0126] Specifically, let the hypothesis have h a Even if the certificate matching the ticket is transitive (e.g., with the help of a strong ambiguity detection mechanism), there may still be security and liveness issues. Figure 1 In Figure 2, two scenarios are shown that are indistinguishable to honest node p4, but the states of other honest nodes are different. In both cases, p2 is Byzantine and is the leader. Figure 2 In the first case shown in (a), leader p2 broadcasts its block B2 to all nodes, and p1 and p3 relay B2. By t = 2Δ, both p1 and p3 have collected B2's certificates and forwarded them to all nodes. By t = 3Δ, since no ambiguity is detected, both p1 and p3 deliver B2. After t = 3Δ, the sleeping node p4 wakes up and receives B2's certificate. At the same time, it also receives B′2 from p2, which is a conflicting block with B2.

[0127] Figure 2 (b) describes another scenario. Unlike the first scenario, p2 sends B2 to p1 and B′2 to p3 and p4. Since p2 received the echo messages for B2 and B′2, it possesses two certificates, each with f+1 matching echo messages. It sends the certificate for B2 to p4. The two scenarios are indistinguishable to p4. However, in scenario 2, no honest node delivers any blocks. In contrast, in scenario 1, p1 and p3 deliver B2, in which case p4 should be locked to B2.

[0128] Furthermore, Figure 3 Comparison of MMR and Koala-1. GA indicates graded agreement.

[0129] Use h a As the arbitration size, and with h a The certificate of the matching ticket can be transferred while building a secure protocol (to solve the indistinguishability problem). This is achieved through a carefully designed double confirmation mechanism and an equivalent error detection mechanism. The double confirmation mechanism requires that each honest node can only vote for the block that extends block B, provided that there are two certificates, each with h a Matching tickets. These two certificates are used as proof of block B, making the state verifiable by honest nodes. At the same time, the equivalence error detection mechanism ensures that no honest node will decide on an inconsistent value.

[0130] By slightly extending the GPE concept of MMR, it is called Verified Three-Level Proposal Election (VT-GPE). As the name suggests, VT-GPE has three levels instead of two levels in GPE. These three levels mimic the commit-lock-prepare relationship of traditional BFT. a With the transferability of quorum enabled, VT-GPE is verified: each node’s input consists of a block and a certificate that can be verified by all honest nodes. This design has three immediate benefits. First, the protocol is significantly simplified compared to existing dormant consensus protocols. Figure 3 As shown, only VT-GPE primitives are required to build an atomic broadcast protocol with latency close to that of traditional synchronous BFT. Secondly, compared to existing dormant atomic broadcast protocols, the protocol also enjoys the advantage of a pipelined model to achieve higher throughput, while it is unclear how to achieve this in existing protocols. Finally, the recovery protocol (which can be used to eliminate assumptions about message delivery and stable storage) can also be greatly simplified, as nodes only need to collect and verify certificates, rather than processing all missing messages.

[0131] S2.1. Propose and verify a valid three-level proposal to elect VT-GPE. The verified three-level proposal to elect VT-GPE is defined as follows:

[0132] Each honest node proposes a block (and a valid proof) and decides either (B, g, σ) (where B≠⊥) or ⊥, with ⊥ being the winning input; where g is a rank, g∈{0,1,2};

[0133] An external validity property is also needed in order to validate VT-GPE;

[0134] At the same time, define a global predicate, determined by the specific application and known to all parties; define σ as a proof of the validity of block B; let the predicate be Q, if Q(B, σ) holds, then B is verified by σ;

[0135] Each honest node decides only one block in a VT-GPE instance, but it may decide the same block multiple times at different levels;

[0136] Furthermore, a validated VT-GPE protocol can achieve the following properties: external validity, consistency, hierarchical delivery, and effectiveness; specifically:

[0137] External validity: If an honest node determines (B, *, *), such that B≠⊥, then there is at least one honest node that satisfies Q(B, σ);

[0138] Consistency: If an honest node decides (B, *, *), and another honest node decides (B′, *, *), then B = B′;

[0139] Hierarchical delivery: if an honest node decides (B, g, *), where g∈{1, 2}, then any honest node decides (B, g-1, *);

[0140] Validity: With probability α > 1 / 2, all honest nodes decide (B, 2, *), where block B is proposed by an honest node.

[0141] Furthermore, in the VT-GPE protocol, VT-GPE ∪ Indicates a VT-GPE instance. ∪ The process consists of two phases: a VRF-based leader election phase and a hierarchical consensus phase. The leader election phase selects a leader, and honest nodes can choose different leaders. The hierarchical consensus phase allows nodes to converge on the leader election result.

[0142] The protocol starts with VRF-based leader election. Each node p i Broadcast one <INPUT,B i , σ i , ρ i ,π i > i Message, where B i It is block p i Proposed, σ i It is block B i Proof, ρ i is the VRF evaluation of the current view number, π i is the proof of VRF evaluation. As defined above, only when Q(B i , σ i ) is established, each node will think that B i Valid. VRF evaluation is used for leader election. Specifically, based on the VRF evaluation received by each node, the producer with the highest VRF is considered the leader, and the corresponding <input> A message is defined as a winning input. If an equivalent <input> If the winning input is ⊥, the program block B associated with the winning input is called the winning program block.

[0143] Since each node may receive different <input> message set, and the winning input may be different, so for each node p i Define it. In particular, if the following conditions are met, p j of<INPUT,B,σ,ρ,π> j It is p i A successful input:

[0144] (1) Q(B, σ) holds;

[0145] (2)π is a valid proof of ρ on the current view number;

[0146] (3)ρ is <input> The highest of all VRF evaluations in the message;

[0147] (4)p i Did not receive another valid<INPUT,B′,σ′,ρ,π> j , where B′≠B.

[0148] After the leader election, from time t = Δ to t = 4Δ, the hierarchical consensus phase is executed. The workflow is as follows: at t = Δ, if node p i is awake, it forwards its winning input and broadcasts a message about the winning block. <echo>information;

[0149] At t = 2Δ, p i Broadcasts a containing its winning input <winner1>message; if p i Receive at least f+1 matching blocks <echo>Messages, nodes will forward these <echo>Message and broadcast a <ready>information;

[0150] At t = 3Δ, p i Broadcasts a containing its winning input <winner2>Message. Similar to the previous round, if p i Receive at least f+1 matching blocks <ready>Messages, nodes will forward these <ready>Message and broadcast a <lock>information;

[0151] When t≥4Δ, there are four conditions: First, if p i Received its winning block B j f+1 matching <lock>message, it will decide B with level 1 j , and f+1 <lock>Message used as B j Proof; secondly, if p i Received f+1 of any block B <ready>and f+1 <winner2>message, it will decide B with rank 1; in this case, f+1 <ready>Messages and f+1 <winner2>The messages are used as proof of B. Finally, if p i Received f+1 of any block B <echo>and f+1 <winner1>message, it will decide B with rank 0. In this case, <echo>Message and <winner1>The message is used as proof of B. Otherwise, p i A special symbol ⊥ will be determined.

[0152] S2.2. Construct the atomic broadcast ABC protocol. This protocol is constructed view by view, following the classic BFT protocol and the previous dormant consensus protocol. In each view, each honest node broadcasts a block and transmits at most one block. The operation process of the atomic broadcast ABC protocol includes:

[0153] The agreement is viewed from Figure 1 Start; in each view v, there is a VT-GPE v VT-GPE instance;

[0154] In each VT-GPE v In each node p i Proposes to extend the block B whose candidate is B, where B is node p i The block is broadcasted. Recall that the idea is to use the level g∈{2, 1, 0} in VT-GPE to mimic the commit-lock-prepare relationship in traditional BFT. To maintain state, each node maintains several local parameters, including candidates and locks, which are initially set to the initial block B. i ; If a block B is determined with level 0 (or 1), the candidate (or lock) is set to B.

[0155] Furthermore, in the atomic broadcast ABC protocol, the global predicate Q of VT-GPE is defined as:

[0156] Given any node p j The proposed value (B, qc) is valid at p if and only if the following conditions hold: i Q(B,qc) holds:

[0157] Condition 1: Block view number view(B) is equal to node p i The current view number of B, qc is a valid prepareQC for B, and the parent block of B is qc's block;

[0158] Condition 2: The view number of qc is at least the same as p i The view number of the lock is the same as the view number of the lock.

[0159] In the protocol, prepareQC is a i The evidence held after deciding a block B at level 0. According to the VT-GPE instantiation, the evidence consists of two certificates, namely f+1 <echo>Messages and f+1 <winner1>message for B. These certificates are essential for verifying B, and they are called a double confirmation mechanism for B. At the same time, ensure that the view number of qc is at least the same as p i The same view number of the locks further prevents forks, which is crucial for both safety and liveness.

[0160] Each node p i Waiting for VT-GPE v There are three possible output results.

[0161] (1) If p i Determine (B, 0, (E(B), W1(B))), p i Set its candidate to B and prepareQC to (E(B), W1(B));

[0162] (2) If p i Determines (B, 1, (R(B), W2(B))), which locks it to B and sets lockedQC to (R(B), W2(B)); the effective lockedQC for block B includes f+1 <ready>and f+1 <winner2>message; the locked parameter is useful for defining the predicate Q, while the lockedQC parameter is only useful in the recovery protocol;

[0163] (3) If p i Having decided on (B, 2, L(B)), it delivers B and all its ancestors.

[0164] In addition, this agreement has the following advantages:

[0165] (1) Pipeline mode: The protocol enjoys the benefits of pipeline mode, where a node can enter the next view v+1 at t=3Δ from the current view v. Although the new instance VT-GPE v+1 is started, but the current instance VT-GPE v Still running until each node decides. To understand why a node can enter the next view at t=3Δ, consider an honest node in VT-GPE v A block B is locked on the network. All nodes that wake up at t=3Δ must receive prepareQC about B (including f+1 <echo>and f+1 <winner1>message). Any honest node proposing a new block must be able to extend B in its updated view. Furthermore, since the lock at t = 4Δ in view v can be updated, the node can use its updated lock to verify the new block at t = Δ in view v+1.

[0166] (2) Fast Path: The protocol has a fast path that delivers a block in 2Δ+26 time. This is achieved by slightly modifying the VT-GPE primitive to a weaker version called wT-GPE. wT-GPE no longer implements the consistency property, but instead has a weak consistency property, defined as follows;

[0167] Condition 3, weak consistency: If an honest node decides (B, g, *), where g ≥ 1, and another honest node decides (B′, *,), then B = B′.

[0168] Compared to the consistency property implemented by VT-GPE, the weak consistency property only achieves consistency when an honest node decides on a block with at least rank 1. With this definition change, it is no longer necessary to use <winner1>and <winner2>Therefore, each node receives t≥3Δ if and only if the sender's <input> When B has the highest VRF evaluation, it decides that block B has a rank of 0. At the same time, each node decides that block B has a rank of 1 or 2 if and only if it receives a valid R(B) or L(B) when t>2Δ is received.

[0169] Although not necessary <winner1>and <winner2>Message, the WT-GPE protocol still utilizes a double confirmation mechanism to make prepareQC consistent with lockedQC in each view. This is achieved by additionally modifying the predicate Q. Specifically, upon receiving a valid prepareQCqc with view(qc) = view(lock), each node also checks whether the block of prepareQC is the same as the block it locked. In this way, only prepareQC that matches lockedQC will be verified by each honest node.

[0170] This technical solution shows that under a known participation model, the latency of synchronous dormant consensus can be close to that of traditional consensus protocols. Specifically, consider a system with n nodes, of which at most f are faulty, and the protocol requires that at any time during the execution of the protocol there are at least h a = f + 1 honest nodes are awake (but the set of honest nodes may vary over time). Under this assumption, a synchronous sleeper consensus protocol, called Koala-1, is constructed with an expected latency of 5Δ + 26 and a best-case latency of 2Δ + 26. In comparison, the best result achieved so far in the unknown participation model is a latency of 14Δ (i.e., MMR), more than twice the latency of Koala-1. This result is close to the latency of 2Δ + δ achieved by traditional synchronous BFT protocols (not in the sleeper model).

[0171] S3. Partially Synchronous Dormant Consensus Processing with Stable Storage: Attacks are conducted in a dormant model without the stable storage assumption; the BFT protocol is converted into a dormant consensus protocol under the stable storage assumption and the minimum intermediate consensus parameters are stored; this step is used to study partially synchronous dormant consensus assuming the existence of stable storage. Ebb-and-Flow briefly mentioned that by assuming the existence of a global wake-up time (GAT), a dormant consensus can be directly obtained using traditional BFT. Combined with the partial synchronization assumption, traditional BFT protocols are always secure in the dormant model and remain active after the global wake-up time (GAT) and the global stability time (GST).

[0172] The above statement is only true if stable storage is assumed and intermediate consensus parameters are stored in stable storage. Most known BFT protocols to date typically do not explicitly discuss what should be stored in stable storage, as this is generally beyond the scope of the consensus problem. Without explicit storage of intermediate parameters, even if GST and GAT are assumed and the assumption of n ≥ 3f + 1 is maintained, traditional BFT may be insecure and non-survivable in the dormant model. Intuitively, this is because if an honest node does not persist its intermediate state during the protocol, it may not be able to recover its state when it wakes up again after a dormant period. Even if the node is synchronized with all honest nodes after waking up, the protocol may still be incorrect.

[0173] S3.1. Run HotStuff, a threshold signature-based BFT consensus algorithm, in a view-by-view manner. HotStuff is described using the syntax of Byzantine Fault Tolerance (BFT). The protocol achieves consistency and validity properties. In HotStuff, all nodes agree on a single leader in each view.

[0174] Specifically, in HotStuff, to reach an agreement on a block, each view includes the following stages:

[0175] Prepare: Leader p k Propose a block B by extending the block with the highest prepareQC received, where prepareQC is nf received in the “prepare” step of the previous view <prepare>A collection of messages; upon receiving a message from p k If the node has a valid proposal B, it will vote for B. <prepare>Ticket, and send the ticket to p k ; nf <prepare>The set of votes constitutes a qc, denoted as prepareQC;

[0176] Pre-commit: p k After collecting B's prepareQC, it will broadcast the prepareQC to all nodes; after receiving the valid prepareQC of B, the node will vote for B. <pre-commit>Ticket and send it to p k ; Similarly, nf <pre-commit>The collection of tickets constitutes a precommitQC;

[0177] Commit: Once the precommitQC is available, the leader p k will broadcast precommitQC to all nodes; after receiving B's precommitQC, the node will lock B (the node will set the locked arbitration certificate lockedQC to precommitQC); then, each node votes for B. <commit>Ticket, and send the ticket to p k ; nf <commit>The collection of tickets constitutes the certificate commitQC;

[0178] Decision: Once B's commitQC is collected, p k The commitQC will be sent to all nodes, and then each node will deliver block B;

[0179] Enter the next view: Before entering the next view, the node will pass <new-view>The message sends its prepareQC to the next leader (which does not necessarily change in every view).

[0180] Furthermore, if a node is locked on block B in a view v, then the node can only vote on blocks in subsequent views that extend B. When a node learns that nf nodes are not locked on B, it may unlock on B. In particular, the prepareQC of a conflicting block with a higher view number than B serves as proof that the node is unlocked on B.

[0181] HotStuff can utilize pipelining to improve performance, which is also called chained HotStuff. Specifically, the view is changed in each PREPARE phase, so there is only one general phase. <prepare>The vote is also for B's parent block <pre-prepare>Voting and voting on B's ancestor block <commit>vote.

[0182] S3.2. Attacking HotStuff in a dormant model without the stable storage assumption. First, assume that in a partially synchronous network, we can assume that there is a network scheduler, i.e., the adversary, during the asynchronous period.

[0183] Furthermore, during the asynchronous period, we consider an adversary (i.e., the network scheduler) manipulating the network, which is the same as the situation assumed by the asynchronous protocol; however, after the global stability time GST, the network becomes synchronized;

[0184] Furthermore, the adversary controls nodes that may enter a sleeping state; in this case, the sleeping nodes are still honest but cannot process any messages while they are sleeping;

[0185] Therefore, it is necessary to attack the dormant nodes at this time to wake them up and ensure the correct operation of the BFT protocol.

[0186] Specifically, if Figure 4 The attack is shown in Figure 1, where there are four nodes, of which p2 is faulty. Consider an adversary (i.e., the network scheduler) manipulating the network during periods of desynchronization, as assumed for asynchronous protocols. Note that in a partially synchronous network, one can assume the existence of a network scheduler during periods of desynchronization. However, after GST, the network becomes synchronized. Furthermore, the adversary controls nodes that can enter a dormant state. In this case, the dormant nodes are still honest, but cannot process any messages while they are dormant. Under these assumptions, the attack proceeds as follows:

[0187] Figure 4 In the figure, (a) is the node state in view v-1; (b) p3 goes to sleep at the end of view v-1 and wakes up at the beginning of view v; it loses its lockedQC and sets its lockedQC to the genesis block B0; (c) the faulty leader p2 creates a block in view v that extends B h-1 The fork is a QC that is able to collect votes from p2, p3, and p4. Since p1 passes block Bh, and p3 and p4 pass blocks B′h, safety is violated.

[0188] Specifically, in the v-1th view, as Figure 4 In (a), p1 is the leader and proposes block Bh. After p1 collects a commitQC, it passes block Bh, and nodes p1, p2, and p3 lock on Bh. During this time, the network scheduler delays the message received by p4. As a result, despite being honest, p4 does not receive any messages regarding Bh. After that, p3 enters a dormant state.

[0189] like Figure 4 As shown in (b), the nodes enter the vth view and p2 becomes the leader. Then, in the vth view, node p3 wakes up. Since p3 does not have stable storage, it loses its lockedQC. Therefore, lockedQC is set to the genesis block B0. In the vth view, the leader p2 is faulty and proposes a new block B′ h , which extends B h-1 (B h-1 The parent block is B h ). Since B′ h With B h Conflict, node p1 believes that proposal B′ h Invalid and will not be B′ h However, p2, p3, and p4 can vote for B′ h , because p2 is faulty and the lockedQC of p3 and p4 do not conflict with B′h.

[0190] Finally, if Figure 4 As shown in (c), node p1 delivers data block Bh, and nodes p3 and p4 deliver data blocks B′h, where B′h and Bh are conflicting, which violates the security properties of the protocol.

[0191] S3.3, a mature dormant consensus protocol under the stable storage assumption, transforming the traditional BFT protocol into a dormant consensus protocol while storing the minimum intermediate consensus parameters in stable storage;

[0192] Based on the aforementioned attacks, traditional BFT protocols can only operate correctly under the standard n ≥ 3f + 1 assumption, provided that stable storage is used. However, storing all intermediate consensus parameters in stable storage significantly degrades system performance. Therefore, an interesting research question is: under the assumptions of n ≥ 3f + 1 and stable storage, can traditional BFT protocols be transformed into dormant consensus protocols, while also storing minimal intermediate consensus parameters in stable storage?

[0193] Using HotStuff as an example, we demonstrate that the minimum requirements for stable storage are a view number and a locked QC. In other words, if an honest replica loses its current view number when it enters a dormant state, it can only catch up with other replicas and learn the latest view number after waking up. A replica may re-enter the same view, in which case it might vote for a block that conflicts with a block it previously voted on. Consequently, two conflicting QCs may be generated within the same view, violating the safety property. To ensure safety within a view, the highest view v at the time a replica voted should be stored in stable storage.

[0194] at the same time, Figure 4 The attack described in shows that cross-view safety can be violated if a replica loses its lockedQC. We show that storing lockedQC in stable storage is sufficient to ensure cross-view safety. Specifically, if a block B is delivered, then a majority of replicas will be locked on B. To deliver a block B′ that conflicts with B, at least a majority of honest replicas must vote for B′. Since an honest replica has set its lockedQC to B, it will never vote for a block that conflicts with B. Consider Figure 4 Consider the example mentioned in . At the beginning of view v, p3 recovers the lockedQC of block Bh from its stable storage. In view v, leader p2 proposes a new block B′h that extends Bh-1 (the parent block of Bh). Since B′h conflicts with Bh, replicas p1 and p3 do not consider the proposal B′h valid and will not vote for B′h. Therefore, only p2 and p4 can vote for B′h. prepareQC, precommitQC, or commitQC cannot form B′h, so no honest replica will deliver block B′h.

[0195] The findings validate the analysis, concluding that storing all consensus parameters in stable storage is not necessary to build a protocol that is both secure and active in the dormant model.

[0196] This technical solution demonstrates that, by assuming the traditional n ≥ 3f + 1 restriction, partially synchronous dormant consensus protocols can only be implemented by assuming stable storage. Furthermore, it is not possible to directly use known BFT to obtain a dormant consensus protocol without explicitly specifying which intermediate consensus parameters are stored in stable storage. Specifically, some edge cases can easily break the protocol in the dormant model by not storing any intermediate parameters in stable storage. While storing all intermediate parameters in stable storage is an option, it is typically expensive due to the frequent disk I / O involved. For example, when implementing BFT-SMaRt as a consistent key-value store where all consensus data is stored in stable storage, the throughput is only 1% of its storage-free version. Even using fast stable storage such as SSDs, the system's throughput is only 23% of its storage-free version. Instead of storing all intermediate parameters, HotStuff only requires storing the view number and locked QCs to achieve dormant consensus in this model.

[0197] S4. Adjust the quorum of the main protocol based on Koala-2, and modify the view change protocol to include a timeout arbitration certificate (QC) mechanism; introduce a new recovery protocol to catch up after the dormant node recovers; among them, the Koala-2 protocol inherits the consistency properties of HotStuff.

[0198] This step is used to study partially synchronous dormant consensus without the stable storage assumption. We show that the condition required to ensure safety and liveness is n ≥ 3f + 2s + 1, where s is the maximum number of honest nodes that can be dormant simultaneously. We show that the NFS quorum is a lower bound for dormant consensus without the stable storage assumption.

[0199] Continuing with HotStuff as an example, we convert the protocol to a dormant consensus protocol. The main workflow is almost identical to that of HotStuff. We only need to adjust the quorum of the main protocol and modify the view change protocol (i.e., leader election) to include a timeout QC mechanism. Furthermore, we introduce a new recovery protocol to enable dormant nodes to catch up after recovery. This conversion is general and can be extended to other partially synchronous BFT protocols.

[0200] S4.1. Demonstrate a correct recovery protocol in Koala-2 and modify the view change protocol to complete the conversion of the BFT protocol to a dormant consensus protocol.

[0201] Specifically, we set the lower bound as n≥3f+2s+1. Considering f failures and s sleeping nodes, the Byzantine quorum that can tolerate f failures is set to Therefore, two Byzantine quorums always overlap in at least one honest node. To illustrate why this is the case, each Byzantine quorum consists of honest nodes. Therefore, two mutually disjoint Byzantine quorums have at least n-f+1 honest nodes. Since there are nf honest nodes in total, there is at least one overlapping honest node in the two Byzantine quorums.

[0202] Now we need to consider availability and responsiveness (protocol progress after gathering information from quorum nodes). Since f+s replicas may not be responsive, the number of awake honest replicas in the system must be equal to or greater than the quorum size. This condition is satisfied only when . Therefore, n≥3f+2s+1.

[0203] If the GAT assumption is taken into account, the bound can be lowered to n ≥ 3f + s + 1. Specifically, let β1 be the quorum size in the main protocol. The validity requirement can be modified to β1 ≤ nf, since eventually every honest node will receive information from all honest nodes (after GAT). However, without stable storage, recovering nodes need to gather information from other awake nodes to recover their local parameters. Even after GAT, there is no guarantee that all honest nodes will respond, as some of them may be recovering. Since at most s honest nodes may be asleep simultaneously, at most f + s nodes in the system may be unavailable. To ensure proper operation of the system, we require β2 ≤ nfs, where β2 represents the amount of information the recovering node needs to gather. Furthermore, to ensure safety, the recovering node should receive information from at least one honest node in each quorum. Therefore, β1 and β2 should overlap in at least f + 1 nodes, meaning β1 + β2 - n ≥ f + 1. In summary, the lower bound is n ≥ 3f + s + 1.

[0204] Koala-2 without the GAT assumption: Based on the discussion above, HotStuff's quorum size can be simply changed from nf to nfs to ensure protocol correctness. However, it is still necessary to ensure that any honest node that has just recovered does not vote for the wrong block to avoid violating the safety property. Therefore, only a correct recovery protocol needs to be demonstrated in Koala-2. However, achieving both intra-view and cross-view security is still non-trivial, and this transition is accomplished by modifying the view change protocol.

[0205] To ensure safety within a view, it is sufficient to ensure that no QC is formed for two conflicting blocks. At first glance, this can already be achieved using the quorum intersection rule of Byzantine quorum. However, it is also necessary to ensure that a recovering node does not vote twice for conflicting blocks within the same view (once before it went to sleep, and once after it recovered). In practice, without the assumption of stable storage, this requirement can only be achieved through the recovery protocol. Therefore, in the recovery protocol, each recovering node needs to synchronize the latest view number with the other nodes. This is achieved using a special type of QC called timeoutQC. Each timeoutQC is generated during a view change. By using a timeoutQC, a node can confirm that the view number it obtains during recovery is at least the same as the view number before it went to sleep.

[0206] An atomic QC acquisition mechanism is employed to address this issue. In the recovery protocol, the recovering node can use information obtained from the timeoutQC mechanism to confirm the time at which the lost lockedQC has been stored by a sufficient number of honest nodes (specific view numbers). Using this information provided by the recovering node, each awake node will avoid sending its lockedQC to the recovering node until it is confirmed that its lockedQC is indeed the one required by the recovering node. This ensures that the recovering node always obtains the correct lockedQC, thus achieving cross-view security.

[0207] S4.2. Modified view change protocol and recovery protocol: When a timeout occurs under normal circumstances, the modified view change protocol is triggered and the steps of the recovery protocol are executed;

[0208] Specifically, the modified view change protocol triggering process is as follows:

[0209] When node p i When a timeout occurs within view v, it stops normal operation and broadcasts<TIMEOUT,v> iMessage;

[0210] nfs matching from different nodes <timeout>The collection of messages forms a timeout QC;

[0211] After receiving a valid timeout QC for view v, p i Will continue to view v+1;

[0212] To speed up the view changing process, p i You can receive f+1 views of v <timeout>Broadcast after message<TIMEOUT,v> i information;

[0213] When p i When receiving a timeout QC for view v, it forwards the timeout QC to all nodes.

[0214] Furthermore, the steps of the recovery protocol include the following:

[0215] S4.2.1. Get timeout QC: Recovered node p i First broadcast <recovery-1>message; upon receiving <recovery-1>After receiving the message, any awake node will send a i Respond to the latest timeout QC (i.e., by <echo-1>message); once nfs valid timeout QC is received, p i The view with the highest number will be selected h ; Then, p i Wait for a view number v ≥ v before going to the next step h +2 for timeout QC;

[0216] S4.2.2, Atomic QC acquisition mechanism: After receiving the view number v≥v h After the timeout QCtc of +2, p i Set its local timeout QC to tc and broadcast<RECOVERY-2,tc> i message; any awake node that receives this message will first initiate the view change protocol and then proceed to view view(tc)+1; then, the node sends a i Send a<ECHO-2,curView,(prepareQC,lockedQC)> Message, where curView is the current view number; when p i Received a view number higher than v h +2 nfs <echo-2>message, it sets its own lock's quorum certificate lockedQC to the highest lockedQC in the message, and sets its prepareQC to the highest prepareQC; after that, p i Set the current view number to view(timeoutQC)+1 and become awake.

[0217] In this technical solution, in a partial synchronization model that does not assume stable storage, it is assumed that Where n is the number of nodes and f is the number of failed nodes. is a tight bound on dormant consensus without assuming stable storage, where s is the maximum number of honest nodes that may enter the dormant state at the same time. Rephrasing this bound, we have n ≥ 3f + 2s + 1. Moreover, by assuming the existence of a global awake time (GAT), the bound on s can be further improved to n - 3f - 1 (i.e., h a =2f+1 and n≥3f+s+1). HotStuff is converted to a dormant consensus protocol called Koala-2, which preserves a latency of 7δ. Koala-2 is built upon a timeout QC mechanism and an efficient recovery protocol for dormant nodes to restore their state upon recovery.

[0218] Those skilled in the art will appreciate that the process of implementing all or part of the steps of the above embodiments may be accomplished by hardware, or by instructing related hardware through a program.

[0219] The above shows and describes the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are merely preferred examples of the present invention and are not intended to limit the present invention. Various changes and improvements may be made to the present invention without departing from the spirit and scope of the present invention. Such changes and improvements fall within the scope of the present invention. The scope of protection claimed in the present invention is defined by the appended claims and their equivalents. < / timeout> < / timeout> < / commit> < / prepare> < / commit> < / commit> < / prepare> < / prepare> < / prepare> < / echo> < / ready> < / echo> < / echo> < / echo> < / ready> < / ready> < / lock> < / lock> < / lock> < / ready> < / ready> < / ready> < / echo> < / echo> < / echo> < / timeout> < / timeout> < / commit> < / commit> < / prepare> < / prepare> < / prepare>

Claims

1. The dormant consensus conversion method of the Byzantine fault-tolerant protocol is characterized by: The steps include: S1. Construct a dormant consensus conversion unit. The system model and component modules of this unit include at least: Byzantine fault tolerance (BFT) protocol, network model and communication channel, dormant model, encryption assumptions, program blocks, Byzantine arbitration and arbitration certificates, and hierarchical proposal election (GPE) protocol. S2. Build the fast synchronous dormant consensus atomic broadcast protocol Koala-1 and the partially synchronous dormant consensus Koala-2 without the stable storage assumption, and use a secure synchronous GPE protocol to build the atomic broadcast ABC protocol; S3. Partial synchronization dormancy with stable storage: Attack in a dormancy model without the stable storage assumption; convert the BFT protocol into a dormancy consensus protocol under the stable storage assumption and store the minimum intermediate consensus parameters; S4. Adjust the quorum of the main protocol based on Koala-2, and modify the view change protocol to include a timeout arbitration certificate QC mechanism; introduce a new recovery protocol to catch up after the dormant node recovers.

2. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 1 is characterized by: In step S1, the system model and component modules of the dormant consensus conversion unit: In the Byzantine Fault Tolerance (BFT) protocol, the client submits the transaction and the node delivers the transaction. The client gets the final response to the submitted transaction from the response; in a BFT system consisting of n nodes, there will be at most nodes malfunction arbitrarily under the control of an adversary; These faulty nodes are also called Byzantine faults, while the nodes that do not fail are called honest nodes; In the network model and communication channels, a synchronous network or a partially synchronous network is adopted; In the sleeping model, sleeping nodes are either awake or asleep; awake nodes actively participate in execution, while sleeping nodes do not execute any code of the protocol and do not send or receive any information; In the encryption assumption, digital signatures with public key infrastructure PKI are used; In the program block, block B represents a batch of transactions, and the blocks are sorted in the form of a chain; In Byzantine quorum and arbitration certificates, Byzantine quorum represents a specific number of nodes; To reach consensus, honest nodes must obtain matching votes from a Byzantine quorum; A set of signatures signed by a Byzantine quorum is called a quorum certificate QC.

3. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 2 is characterized by: In step S2, when constructing the atomic broadcast ABC protocol using a secure synchronous GPE protocol, a practical dormant consensus is first established in a known participation model, with a latency close to that of a traditional synchronous BFT protocol. The GPE protocol works as follows: Consider each node proposing a block to broadcast; the protocol starts with a round in which each node broadcasts the proposed block, and a leader election mechanism is usually embedded in this round; Assuming all honest nodes agree on a common leader, each node will then propagate the blocks it receives from the leader back to all other nodes. Once received Return blocks , each node will forward the certificate to all nodes in the third round; If a node detects leader ambiguity, it forwards the ambiguous message to all nodes; If you receive If the node has a valid certificate for block B and no ambiguity is detected at the end of the third round, the node will decide on block B at level 1; If no ambiguity is detected in the second round, and a valid certificate for B is received at the end of the third round, any undecided node decides on block B with rank 0; When a node decides on a block B at level 1, it will deliver block B in the ABC protocol.

4. The dormant consensus conversion method of the Byzantine fault tolerant protocol according to claim 3 is characterized in that: The step S2 comprises: S2.1 Propose and verify a valid three-level proposal to elect VT-GPE; S2.

2. Construct the atomic broadcast ABC protocol. This protocol is constructed view by view following the classic BFT protocol and the previous dormant consensus protocol. In each view, each honest node broadcasts a block and transmits at most one block. In step S2.1, the three-level proposal election VT-GPE for verification is defined as follows: Each honest node proposes a block and a valid proof and decides whether , or ,in , Enter to win; where, It's a level, ; An external validity property is also needed in order to validate VT-GPE; At the same time, define a global predicate that is determined by a specific application and known to all parties; Defined as a block Proof of the validity of ; let the predicate be ,if If established, quilt verify; Each honest node decides only one block in a VT-GPE instance, but it can decide the same block multiple times at different levels; Furthermore, a validated VT-GPE protocol can achieve the following properties: external validity, consistency, grade delivery, and effectiveness.

5. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 4 is characterized by: In step S2.2, the operation process of the atomic broadcast ABC protocol includes: The protocol starts with view 1; in each view v, there is a of Examples; In each In each node Proposes to extend the block whose candidate ,in is a node Broadcasted blocks; to maintain state, each node maintains several local parameters, including candidates and locks, initially set to the genesis block ; If a block is determined at level 0 or 1, the candidate or lock is set to .

6. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 5 is characterized by: In the atomic broadcast ABC protocol, Global predicates Defined as: Given any node Proposed value , if and only if the following conditions hold, Department Established: Condition 1: Block view number Equal to node The current view number of qc is a Effective prepareQC, and The parent block is the block of qc; Condition 2: The view number of qc is at least The view number of the lock is the same as the view number of the lock.

7. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 6 is characterized in that: The step 3 comprises: S3.

1. Run HotStuff, a threshold signature-based BFT consensus algorithm, on a view-by-view basis, using the syntax of Byzantine Fault Tolerance (BFT). In HotStuff, all nodes agree on a single leader in each view. S3.2, attacking HotStuff in a dormant model without the stable storage assumption; S3.3, a mature dormant consensus protocol under the stable storage assumption, transforming the traditional BFT protocol into a dormant consensus protocol while storing the minimum intermediate consensus parameters in stable storage; In step S3.1, in HotStuff, to reach an agreement on a block, each view includes the following stages: Prepare: Leader The highest received through extension to propose a block B, where Received during the "prepare" step of the previous view indivual A collection of messages; upon receiving If the node has a valid proposal B, it will vote for B. Tickets and send them to ; indivual The set of votes constitutes a qc, denoted as ; Pre-submit: After collecting B After that, it will broadcast the ; Upon receipt of a valid B After that, the node will vote for B Ticket and send it to ;same, indivual The collection of tickets constitutes a precommitQC; Commit: Once precommitQC is available, the leader will broadcast precommitQC to all nodes; after receiving B's precommitQC, the node will lock B; then, each node votes for B. Tickets and send them to ; indivual The collection of tickets constitutes the certificate commitQC; Decision: Once B's commitQC is collected, The commitQC will be sent to all nodes, and then each node will deliver block B; Enter the next view: Before entering the next view, the node will pass The message sends its prepareQC to the next leader.

8. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 7 is characterized by: In step S3.2, the attack on HotStuff in the dormant model without the stable storage assumption is as follows: First, we assume that in a partially synchronous network, there exists a network scheduler, i.e., the adversary, during the asynchronous period. Furthermore, during the asynchronous period, we consider an adversary manipulating the network, which is the same as the situation assumed by the asynchronous protocol; however, after the global stability time GST, the network becomes synchronized; Furthermore, the adversary controls nodes that may enter a sleeping state; in this case, the sleeping nodes are still honest but cannot process any messages while they are sleeping; Therefore, it is necessary to attack the dormant nodes at this time to wake them up and ensure the correct operation of the BFT protocol.

9. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 8 is characterized in that: The step S4 comprises: S4.

1. Demonstrate a correct recovery protocol in Koala-2 and modify the view change protocol to complete the conversion of the BFT protocol to a dormant consensus protocol. S4.

2. Modified view change protocol and recovery protocol: When a timeout occurs under normal circumstances, the modified view change protocol is triggered and the steps of the recovery protocol are executed; In step S4.2, the modified view change protocol triggering process is as follows: When the node When a timeout occurs within view v, it stops normal operation and broadcasts information; From different nodes match The collection of messages forms a timeout QC; Upon receiving the view After the effective timeout QC, Will continue to view ; To speed up the view changing process, On receiving the view of indivual Broadcast after message information; when Receive View When a timeout QC is received, it forwards the timeout QC to all nodes.

10. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 9 is characterized in that: In step S4.2, the steps of restoring the protocol include the following: S4.2.

1. Get Timeout QC: Recovered Node First broadcast message; upon receiving After receiving the message, any awake node will send Respond to the latest timeout QC, i.e. pass Message; once received An effective timeout QC, The view with the highest number will be selected ;Then, Wait for a view number before going to the next step Overtime QC; S4.2.2, Atom QC acquisition mechanism: After receiving the view number After the timeout QC, Set its local timeout QC to tc and broadcast message; any awake node that receives this message will first initiate the view change protocol and then proceed to view ; Then, the node sends Send a Message, which is the current view number; when Received view number higher than of indivual message, it sets its own lock's quorum certificate lockedQC to the highest lockedQC in the message, and sets its prepareQC to the highest prepareQC; after that, Set the current view number to , and becomes awake.

Images