Sleep consensus conversion method of Byzantine fault-tolerant protocol

Abstract

The invention relates to the technical field of distributed computing, in particular to a sleep consensus conversion method for a Byzantine fault-tolerant protocol. Comprising the following steps: S1, constructing a sleep consensus conversion unit; s2, constructing a rapid synchronous deep sleep consensus atomic broadcast protocol Koala-1 and a partial synchronous deep sleep consensus Koala-2 without a stable storage hypothesis; s3, performing synchronous sleep consistency processing on the stably stored part: attacking in a sleep model without a stable storage hypothesis; in the stable storage assumption, the BFT protocol is converted into a sleep consensus protocol, and the minimum intermediate consensus parameter is stored; and S4, adjusting the quorum number of the main protocol based on Koala-2, and modifying the view change protocol to contain a timeout arbitration certificate QC mechanism. According to the invention, a synchronous atomic broadcast protocol called Koala-1 is provided, so that the network delay is reduced; designing a specific structure of a partial synchronization model, and obtaining a safe sleep consensus through a stable storage hypothesis; and partial rapid synchronous sleep consensus without stable storage is realized.

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, which allows a group of nodes to reach consensus in the presence of arbitrary failures. Classical Byzantine fault-tolerant protocols assume that nodes know each other's identities and that non-faulty nodes should always remain online. Recently, the dormant consensus model has been introduced. In dormant consensus, a certain number of nodes may go offline (dormant) unpredictably and then come back online (awake). This model is also called the crash-recovery model in the distributed computing literature, describing 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 which 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 sleeping 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 sleeping consensus have also been studied. For example, Gafni and Losa studied Byzantine agreements that achieve constant delay in the sleeping model. Meanwhile, a recent work by D'Amato, Losa, and Zanolini studied the asynchronous resilience of synchronous sleeping consensus. Their idea is to allow synchronous protocols to operate safely even during intermittent asynchronous periods.

[0006] (2) Disk-independent crash recovery. In the distributed computing literature, the sleep mode is also called the 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 types of failures. Some protocols can tolerate both Byzantine failures and crash failures. 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 implements 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 14Δ latency, where Δ is the bound of the network latency. The latency 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 that proposed in the Ebb-and-Flow protocol and its follow-up 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 wakes up). As with traditional BFT protocols in the partially synchronous model, a system with n nodes can tolerate Failure (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-mentioned background technology.

[0013] In order to solve the above technical problems, one of the purposes 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 which include at least: Byzantine fault tolerance BFT protocol, network model and communication channel, dormant model, encryption assumption, program block, Byzantine arbitration and arbitration certificate, and hierarchical proposal election GPE protocol;

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

[0016] S3. Partial synchronization dormant consistency processing for stable storage: Attack in a dormant model without the stable storage assumption; convert the BFT protocol into a dormant 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 sleeping node recovers.

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

[0019] In the Byzantine Fault Tolerant (BFT) protocol, the client submits a transaction (request) and the node delivers the transaction; the client obtains the final response to the submitted transaction from the response; in a BFT system consisting of n nodes, at most f nodes will fail arbitrarily under the control of the 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, nor 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 is used to represent a batch of transactions, and the blocks are sorted in the form of a chain;

[0024] 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).

[0025] As a further improvement of the technical solution, in step S2, when using a secure synchronous GPE protocol to construct the atomic broadcast ABC protocol, a practical dormant consensus is first established in a known participation model, and its delay time is close to that of the traditional synchronous BFT protocol; wherein 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 usually a leader election mechanism is embedded in this round;

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

[0028] Once f+1 return 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 at 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 nodes that have not yet decided will decide on block B with level 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 the present 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, which 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] Among them, 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 ⊥, where ⊥ is the winning input; where g is a rank, g∈{0,1,2};

[0038] An external validity property is also needed in order to validate the 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 technical solution, in step S2.2, the operation process of the atomic broadcast ABC protocol includes:

[0043] The agreement is based on 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 candidates are, where B is the 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 decided with level 0 (or 1), the candidate (or lock) is set to B.

[0045] As a further improvement of the 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 At 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 the block of qc;

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

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

[0050] S3.1. Run the threshold signature-based BFT consensus algorithm HotStuff in a view-by-view manner, using the syntax of Byzantine Fault Tolerance BFT to describe HotStuff; in HotStuff, all nodes will agree on the only leader in each view;

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

[0052] S3.3, a mature dormant consensus protocol under the assumption of stable storage, which transforms the traditional BFT protocol into a dormant consensus protocol and stores the minimum intermediate consensus parameters in stable storage at the same time;

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

[0054] Prepare: Leader 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, the prepareQC will be broadcast to all nodes; after receiving a valid prepareQC of B, the node will vote for B. <pre-commit>ticket and send it to p k ; Similarly, nf <pre-commit>A 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>Tickets and send them to p k ; nf <commit>The collection of tickets constitutes the certificate commitQC;

[0057] Decision: Once B's commitQC is collected, p k 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 the technical solution, in step S3.2, the attack on HotStuff in the sleeping model without the stable storage assumption is specifically:

[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, the same as assumed by the asynchronous protocol; however, after the global stability time GST, the network becomes synchronized;

[0062] Furthermore, the adversary controls nodes that may go into 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 sleeping nodes at this time to wake them up and ensure the correct operation of the BFT protocol.

[0064] As a further improvement of the present 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 the 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] Among them, in step S4.2, the modified view change protocol triggering process is:

[0068] When node p i When the timeout elapses 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 change process, p i After receiving 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 the 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 the message, any awake node will send a i Respond to the latest timeout QC (i.e., through <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 conversion method of the Byzantine fault-tolerant protocol, a synchronous atomic broadcast protocol called Koala-1 is proposed to reduce network latency, with an expected latency of 5Δ+2δ and a latency of 2Δ+2δ in the best case;

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

[0079] 3. In the dormant consensus conversion method of the Byzantine fault-tolerant protocol, in a partially synchronous network, but without assuming stable storage, the bound of n≥3f+2s+1 can be proved, without considering the global wake-up time (GAT) assumption (all honest nodes wake up after GAT) and the bound of n≥3f+s+1, to achieve a 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 cases of exemplifying the synchronous atomic broadcast protocol in the sleeping model in the present invention;

[0082] Figure 3 It 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 a 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 be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0085] Example 1

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

[0087] S1. Construct a dormant consensus conversion unit, the system model and component modules of which include at least: Byzantine fault tolerance BFT protocol, network model and communication channel, dormant model, encryption assumption, program block, Byzantine arbitration and arbitration certificate, and hierarchical proposal election GPE protocol;

[0088] Specifically, in the Byzantine Fault Tolerant (BFT) protocol, the client submits a transaction (request) and the node delivers the transaction; the client obtains the final response to the submitted transaction from the response; in a BFT system consisting of n nodes, at most f nodes will fail arbitrarily under the control of the 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 delivering tx first. ′ ;

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

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

[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 eventually pass on the message m.

[0095] Among them, although BFT and atomic broadcast do not expose the order to API, most protocols give 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 limit Δ on the information processing and transmission delay. In addition, we assume that there is a completely synchronized clock, that is, all nodes can access a common global clock. In the partially synchronous model, there is still an upper limit, but the value of Δ is unknown. Another concept of the partially synchronous model is that there is an unknown global stable time (GST), after which information sent between two honest nodes will arrive within a fixed delay.

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

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

[0100] In the system, every honest node can become dormant, and its state can be changed at any time under the control of the adversary without prior notice. In practice, this means that nodes are allowed to leave or rejoin the execution of the protocol at will without notifying other nodes. In the distributed computing literature, the "sleeping" model is consistent with the "crash-recovery" model, in which nodes can repeatedly crash and recover. It is worth noting that an honest node may suffer "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 wake-up time (GAT) assumption, that is, after the GAT, every sleeping node will be awakened, then our partial synchronization protocol can be realized: 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 The signed information μ. Assume that 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 obtain a pseudo-random value ρ i and a proof that π i Using Pi i and node p i Anyone can verify the public key of i Is it VRF? i The correct evaluation of the input μ.

[0104] In the program block, a batch of transactions is represented by block B, and the blocks are ordered in the form of a chain; the previous block of B is called its parent block. The first block in the chain is called the genesis block B0. If B′ is the ancestor of B in the blockchain, then block B extends block B′. If both blocks B and B′ do not extend the other block, they conflict with each other.

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

[0106] The concept of GPE is 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. Construct 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 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 system. 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 passing are stable, that is, once a node becomes awake at time t, it will immediately receive all messages sent to it by any honest node before time t-Δ. Among them, the Koala-1 protocol follows the traditional atomic broadcast model.

[0111] Specifically, we build a practical dormant consensus in a known participation model with latency close to that of traditional synchronous BFT protocols. In particular, Koala-1 has a fast path that achieves 2Δ+26 latency, which occurs when all awake nodes are honest. At the same time, Koala-1 has an expected latency of 5Δ+2δ. In comparison, the latency of the state-of-the-art dormant consensus protocol MMR is 14Δ, more than twice the latency of Koala-1. In addition, Koala-1 uses a pipelined model, where nodes can start processing new blocks before the current block is agreed upon.

[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 the quorum size is f + 1 to obtain a synchronous atomic broadcast protocol. In fact, as mentioned in MMR, f + 1 matching votes form an arbitration certificate, and this certificate is transferable, that is, it can be verified by any node. Together with an equivalence detection mechanism to detect whether a node sends inconsistent messages to different nodes, we can obtain a secure synchronous GPE protocol and use this GPE protocol to build the atomic broadcast (ABC) protocol.

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

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

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

[0117] Once f+1 return 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 at 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 nodes that have not yet decided will decide on block B with level 0;

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

[0122] The previous synchronous Byzantine agreement and atomic broadcast protocol also roughly follow this paradigm. Here, the level is very close to the commit-lock relationship in traditional BFT. In other words, for block B, level 0 can be regarded as 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 level 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 sleeping model, an attractive solution is to simply change the size of the Byzantine quorum and convert the above-mentioned protocol into a sleeping consensus protocol. However, even under the known participation model, building a secure sleeping consensus protocol is far from easy. This is mainly because the traditional quorum size can no longer be used as before, because the (probably majority) honest nodes may enter the sleeping 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 point in the protocol execution, there are at least a = f + 1 honest nodes are awake. Use h a The size of the arbitration 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 cases of the synchronous atomic broadcast protocol in the sleep model. In both cases, p2 is a Byzantine node and p4 receives B′2 from p2 and a valid certificate about B2. In the first case, p1 and p3 submit B2. In contrast, in the second case, 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 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 assumption 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 2 shows two scenarios 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 send back B2. By t = 2Δ, both p1 and p3 have collected the certificates for B2 and forwarded them to all nodes. By t = 3Δ, since no ambiguity was detected, both p1 and p3 delivered B2. After t = 3Δ, the sleeping node p4 wakes up and receives the certificate for B2. At the same time, it also receives B′2 from p2, which is a block that conflicts 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 echo messages for B2 and B′2, it has two certificates, each with f+1 matching echo messages. It sends the certificate for B2 to p4. The two cases 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 on B2.

[0128] Further, Figure 3 is a comparison of MMR and Koala-1. GA indicates graded agreement.

[0129] Use h a As the arbitration size, and with h a The certificates matching the tickets are transferable, 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 if there are two certificates, each with h a The two certificates are used as proof of block B, making the state of honest nodes verifiable. At the same time, the equivalent error detection mechanism ensures that no honest node will decide on inconsistent values.

[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 the 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 needed to build an atomic broadcast protocol with a latency close to that of traditional synchronous BFT. Second, the protocol also enjoys the advantage of pipeline mode to achieve higher throughput compared to existing dormant atomic broadcast protocols, 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 election VT-GPE; wherein the verified three-level proposal election 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 ⊥, where ⊥ is the winning input; where g is a rank, g∈{0,1,2};

[0133] An external validity property is also needed in order to validate the 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] In addition, a validated VT-GPE protocol can achieve the following properties: external validity, consistency, grade delivery and effectiveness; specifically:

[0137] External validity: If an honest node determines (B, *, *), such that B≠⊥, then at least one honest node 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. VT-GPE ∪ It includes two phases: the VRF-based leader election phase and the hierarchical consensus phase. The leader election phase selects a leader, and honest nodes can choose different leaders. The hierarchical consensus phase allows each node to converge on the result of the leader election.

[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 consider 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 winning input is set to ⊥. In addition, the program block B related to 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, p j of<INPUT,B,σ,ρ,π> j Yes 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 matches to its winning block <echo>messages, the node 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 matches to its winning block <ready>messages, the node will forward these <ready>message and broadcast a <lock>information;

[0151] When t ≥ 4Δ, there are four conditions: First, if p i Received the 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>Message 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>Messages and <winner1>messages are used as proof of B. Otherwise, p i A special symbol ⊥ will be determined.

[0152] S2.2. Construct the atomic broadcast ABC protocol. The ABC 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 based on 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 candidates are, where B is the node p i The block to be 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 the state, each node maintains several local parameters, including candidates and locks, initially set to the initial block B i ; If a block B is decided 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 At 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 the block of qc;

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

[0159] In the protocol, prepareQC is the 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>Message and f+1 <winner1>message for B. These certificates are essential for verifying B, and we refer to them as B's double confirmation mechanism. At the same time, we 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 from occurring, 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 Determined (B, 1, (R(B), W2(B))), it 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 (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Δ of 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 blockchain. 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 the 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. 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 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 has decided on a block of 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 <input> When B has the highest VRF evaluation, it decides block B with rank 0. At the same time, each node decides block B with rank 1 or 2 when it receives t>2Δ if and only if it receives a valid R(B) or L(B).

[0169] Although not necessary <winner1>and <winner2>message, the wT-GPE protocol still uses a double confirmation mechanism to make prepareQC consistent with lockedQC in each view. This is achieved by additionally modifying the predicate Q. In particular, upon receiving a valid prepareQCqc and view(qc) = view(lock), each node also checks whether the block of prepareQC is the same as the block it locks. 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 change over time). A synchronous dormant consensus protocol, called Koala-1, is constructed under this assumption with an expected latency of 5Δ+26 and a best-case latency of 2Δ+26. In contrast, the best result achieved so far in the unknown participation model is a latency of 14Δ (i.e., MMR), more than twice as large as Koala-1's latency. This result is close to the latency of 2Δ+δ achieved by traditional synchronous BFT protocols (not in the dormant model).

[0171] S3. Partially synchronous dormant consensus processing with stable storage: attack in the dormant model without the stable storage assumption; convert the BFT protocol into a dormant consensus protocol under the stable storage assumption and store the minimum intermediate consensus parameters; this step is used to study the 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, the traditional BFT protocol is always safe in the dormant model and remains active after the global wake-up time (GAT) and the global stabilization time (GST).

[0172] The above statement can only be realized if stable storage is assumed and the intermediate consensus parameters are stored in stable storage. Most BFT protocols known to date usually do not explicitly discuss what should be stored in stable storage, as this is usually beyond the scope of the consensus problem. If the intermediate parameters are not stored explicitly, even if GST and GAT are assumed and the assumption of n≥3f+1 is preserved, 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 restore its state when it wakes up again after sleeping. Even if the node is synchronized with all honest nodes after waking up, the protocol may still be incorrect.

[0173] S3.1. Run the threshold signature-based BFT consensus algorithm HotStuff in a view-by-view manner. Use the syntax of Byzantine Fault Tolerance BFT to describe HotStuff. The protocol can achieve consistency and validity properties. In HotStuff, all nodes will agree on the only leader in each view.

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

[0175] Prepare: Leader 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;

[0176] Pre-commit: p k After collecting B's prepareQC, the prepareQC will be broadcast to all nodes; after receiving a valid prepareQC of B, the node will vote for B. <pre-commit>ticket and send it to p k ; Similarly, nf <pre-commit>A 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>Tickets and send them to p k ; nf <commit>The collection of tickets constitutes the certificate commitQC;

[0178] Decision: Once B's commitQC is collected, p k 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 take advantage of 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, Attack HotStuff in the Sleep Model without 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, the same as assumed by the asynchronous protocol; however, after the global stability time GST, the network becomes synchronized;

[0184] Furthermore, the adversary controls nodes that may go into 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 sleeping nodes at this time to wake them up and ensure the correct operation of the BFT protocol.

[0186] Specifically, 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 the desynchronized period, the same as assumed for the asynchronous protocol. Note that in a partially synchronous network, one can assume the existence of a network scheduler during the asynchronous period. However, after 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 in the sleeping state. Under these assumptions, the attack proceeds as follows:

[0187] Figure 4 In the figure, (a) shows the node status in view v-1; (b) p3 goes into a dormant state 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 fork of , and is able to collect QCs that vote from p2, p3, and p4. Since p1 passed block Bh, and p3 and p4 passed blocks B′h, safety is violated.

[0188] Specifically, in the v-1th view, if Figure 4 As shown in (a), p1 is the leader and it proposes block Bh. After p1 collects a commitQC, it passes block Bh, and nodes p1, p2, and p3 lock on Bh. During this period, the network scheduler delays the message received by p4. Therefore, although p4 is honest, it does not receive any message about Bh. After that, p3 goes to sleep.

[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 assumption of stable storage, which transforms the traditional BFT protocol into a dormant consensus protocol and stores the minimum intermediate consensus parameters in stable storage at the same time;

[0192] According to the attacks mentioned above, traditional BFT protocols can only operate correctly under the standard n ≥ 3f + 1 assumption only under the assumption of stable storage. 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, is it possible to transform a traditional BFT protocol into a dormant consensus protocol and at the same time store the minimal intermediate consensus parameters in stable storage?

[0193] Taking HotStuff as an example, it is shown that the minimum requirements for stable storage are the view number and lockedQC. In other words, if an honest replica loses its current view number when it goes to sleep, then the replica can only catch up with other replicas to understand the latest view number after waking up. There may be a situation where a replica re-enters the same view, in which case the replica may vote for a block that conflicts with the block it voted for before. Therefore, two conflicting QCs may be generated in the same view, violating the safety property. To ensure safety within a view, the highest view v when the 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 Example mentioned in . At the beginning of entering view v, p3 recovers the lockedQC of block Bh from its stable storage. In view v, leader p2 proposes a new block B′h, which 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 building a protocol that is both secure and active in the dormant model does not require storing all consensus parameters in stable storage.

[0196] This technical solution shows that by assuming the traditional n≥3f+1 restriction, a partially synchronous dormant consensus protocol can only be implemented by making a stable storage assumption. In addition, a dormant consensus protocol cannot be directly obtained using known BFT without explicitly specifying which intermediate consensus parameters are stored in stable storage. Specifically, some boundary cases allow the protocol to be easily broken in the dormant model by not storing any intermediate parameters of the protocol in stable storage. Although storing all intermediate parameters in stable storage is an option, it is usually expensive because frequent disk I / 0 is involved. For example, when BFT-SMaRt is implemented 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 with fast stable storage such as SSD, the throughput of the system is only 23% of its storage-free version. Unlike storing all intermediate parameters, only the view number and the locked QC need to be stored to make HotStuff a 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 adopts the consistency properties of HotStuff.

[0198] Among them, this step is used to study the 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 may enter the dormant state at the same time. We show that the quorum of nfs is a lower bound for the dormant consensus without assuming stable storage.

[0199] Still taking HotStuff as an example, we convert the protocol to a dormant consensus protocol. The main workflow is almost the same as in 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. In addition, a new recovery protocol is introduced to catch up after the dormant node recovers. The conversion is general and can be extended to other partially synchronous BFTs.

[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 the dormant consensus protocol.

[0201] Specifically, we set the lower bound to be n≥3f+2s+1. Considering f failures and s sleeping nodes, the Byzantine arbitration 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 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 (the protocol makes progress after gathering information from the quorum nodes). Since f+s replicas may be unresponsive, 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 reduced 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, because eventually every honest node can receive information from all honest nodes (after GAT). However, without stable storage, the recovering node needs to collect information from other awake nodes to recover local parameters. Even after GAT, it is not guaranteed that all honest nodes will respond, because some of them may also be in the recovery state. Since at most s honest nodes may go to sleep at the same time, at most f+s nodes may be unavailable in the system. To ensure the normal operation of the system, we need β2≤nfs, where β2 represents the amount of information that the recovery node needs to collect. In addition, to ensure safety, the recovery 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, that is, β1+β2-n≥f+1. In summary, the lower bound is n≥3f+s+1.

[0204] Koala-2 protocol without GAT assumption: Based on the above discussion, one can simply change the arbitration size of HotStuff from nf to nfs to ensure the correctness of the protocol. However, it is still necessary to ensure that any honest node that has just recovered will not vote for the wrong block, so as not to violate the safety property. Therefore, only a correct recovery protocol needs to be demonstrated in Koala-2. However, achieving intra-view security and cross-view security is still not a trivial matter, and the transition is completed by modifying the view change protocol.

[0205] To ensure safety within a certain view, it is only necessary to ensure that no QC is formed for two conflicting blocks. At first glance, this can already be achieved with 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 stable storage assumption, this requirement can only be achieved by the recovery protocol. Therefore, in the recovery protocol, each recovering node needs to synchronize the latest view number with other nodes. A special type of QC called timeoutQC is used to achieve this. 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 view number before it went to sleep.

[0206] The atomic QC acquisition mechanism is used to solve this problem. In the recovery protocol, the recovering node can use the information obtained from the timeoutQC mechanism to confirm the time when the lost lockedQC has been stored by enough honest nodes (the view number should be specific). Using this information provided by the recovery node, each awake node will avoid sending its lockedQC to the recovery node until it is confirmed that its lockedQC is indeed the QC required by the recovery node. In this way, the recovery node can always obtain the correct lockedQC, thereby 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:

[0209] When node p i When the timeout elapses 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 change process, p i After receiving 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] Further, 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 the message, any awake node will send a i Respond to the latest timeout QC (i.e., through <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 be dormant at the same time. Rephrasing this bound, we have n ≥ 3f + 2s + 1. Moreover, by assuming the existence of a global wake-up 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 the latency of 7δ. To build Koala-2, a timeout QC mechanism and an efficient recovery protocol can be provided to restore the dormant nodes to their state after 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 completed by hardware, or may be completed 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 by the above embodiments. The above embodiments and descriptions are only preferred examples of the present invention and are not intended to limit the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention. The scope of protection of the present invention is defined by the attached 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 which include at least: Byzantine fault tolerance BFT protocol, network model and communication channel, dormant model, encryption assumption, program block, Byzantine arbitration and arbitration certificate, and hierarchical proposal election GPE protocol; S2. Construct the fast synchronous dormant consensus atomic broadcast protocol Koala-1 and the partially synchronous dormant consensus Koala-2 without the assumption of stable storage, and use a secure synchronous GPE protocol to construct the atomic broadcast ABC protocol; S3. Partial synchronization dormant consistency processing for stable storage: Attack in a dormant model without the stable storage assumption; convert the BFT protocol into a dormant 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 sleeping node recovers.

2. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 1 is characterized in that: In step S1, the system model and component modules of the dormant consensus conversion unit: In the Byzantine Fault Tolerant BFT protocol, the client submits the transaction and the node delivers the transaction; The client obtains the final response to the submitted transaction from the response; in a BFT system consisting of n nodes, at most f nodes will fail arbitrarily under the control of the adversary; these failed nodes are also called Byzantine failures, while the nodes that have not failed are called honest nodes; In the network model and communication channels, both synchronous and partially synchronous networks are considered; 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, nor send / receive any information; In the encryption assumption, digital signatures with public key infrastructure PKI are used; In the program block, block B is used to represent a batch of transactions, and the blocks are sorted in the form of a chain; In Byzantine quorum and quorum certificates, Byzantine quorum means a specific number of nodes; To reach consensus, honest nodes must obtain matching votes from the 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 in that: In step S2, when using a secure synchronous GPE protocol to construct the atomic broadcast ABC protocol, a practical dormant consensus is first established in a known participation model, and its delay time is close to that of the traditional synchronous BFT protocol; wherein 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 usually a leader election mechanism is embedded in this round; Assuming all honest nodes agree on a common leader, each node will then send back the blocks it receives from the leader to all other nodes; Once f+1 return blocks B are received, 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 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 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 nodes that have not yet decided will decide on block B with level 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, which 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; Among them, 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 either (B, g, σ) or ⊥, where B≠⊥ and ⊥ is the winning input; where g is a level, g∈{0,1,2}; An external validity property is also needed in order to validate the VT-GPE; 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 σ; Each honest node decides only one block in a VT-GPE instance, but it may 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 in that: 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 VT-GPE v VT-GPE instance; In each VT-GPE v In each node p i Proposes to extend the block B whose candidates are, where B is the 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.

6. The dormant consensus conversion method of the Byzantine fault-tolerant protocol according to claim 5 is characterized in that: In the atomic broadcast ABC protocol, the global predicate Q of VT-GPE is defined as: Given any node p j The proposed value (B, qc) is valid at p if and only if the following conditions hold: i At Q(B,qc) holds: 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 the block of qc; Condition 2: The view number of qc is at least the same as p i The same view number as 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 the threshold signature-based BFT consensus algorithm HotStuff in a view-by-view manner, using the syntax of Byzantine Fault Tolerance BFT to describe HotStuff; in HotStuff, all nodes will agree on the only leader in each view; S3.2, attacking HotStuff in the dormant model without the stable storage assumption; S3.3, a mature dormant consensus protocol under the assumption of stable storage, which transforms the traditional BFT protocol into a dormant consensus protocol and stores the minimum intermediate consensus parameters in stable storage at the same time; Among them, in step S3.1, in HotStuff, in order to reach an agreement on a block, each view includes the following stages: Preparation: 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; once a valid proposal B is received from pk, the node 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;< / prepare> < / prepare> < / prepare> Pre-submit: p k After collecting B's prepareQC, the prepareQC will be broadcast to all nodes; after receiving a valid prepareQC of B, the node will vote for B. <pre-commit>ticket and send it to p k ; Similarly, nf <PRE- <cmmit> A collection of tickets constitutes a precommitQC;< / cmmit> 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; then, each node votes for B <cmmit>Tickets and send them to p k ; nf <commit> The collection of tickets constitutes the certificate commitQC;< / commit> < / cmmit> Decision: Once B's commitQC is collected, p k 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 <new-view> 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 in that: In step S3.2, the attack on HotStuff in the dormant model without the stable storage assumption is specifically as follows: 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; Furthermore, during the asynchronous period, we consider an adversary manipulating the network, the same as assumed by the asynchronous protocol; however, after the global stability time GST, the network becomes synchronized; Furthermore, the adversary controls nodes that may go into 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 sleeping 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 the 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; Among them, in step S4.2, the modified view change protocol triggering process is: When node p i When the timeout elapses within view v, it stops normal operation and broadcasts<TIMEOUT,v> i information; nfs matching from different nodes <timeout> The collection of messages forms a timeout QC;< / timeout> After receiving a valid timeout QC for view v, p i Will continue to view v+1; To speed up the view change process, p i After receiving f+1 views of v <timeout>Broadcast after message<TIMEOUT,v> i information;< / timeout> When p i When receiving a timeout QC for view v, 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 p i First broadcast <recovery-1>message; upon receiving <recovery-1>After the message, any awake node will send a i Respond to the latest timeout QC, i.e. through <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; S4.2.2, Atomic QC acquisition mechanism: After receiving the timeout QC tc 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 curVieew 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.

Images