Lodestone: An Efficient Byzantine Fault-Tolerant Protocol in Consortium Blockchains

We present Lodestone, a chain-based Byzantine fault-tolerant (BFT) state machine replication (SMR) protocol under partial synchrony. Lodestone enables replicas to achieve consensus with two phases of voting and enjoys (1) optimistic responsiveness and (2) linear communication complexity on average. Similar to the state-of-the-art chain-based BFTprotocols, Lodestone can be optimized with a pipelining idea elegantly. We implement pipelined Lodestone and deploy experiments to evaluate its performance. *e evaluation results demonstrate that Lodestone has a lower latency than HotStuff under various workloads.


Introduction
Consensus in blockchain systems, known as state machine replication (SMR), has attracted more and more interest in recent years. When focusing on permissioned blockchains on so-called consortium blockchains, chain-based Byzantine fault-tolerant (BFT) SMR protocols [1][2][3][4][5][6][7][8] under partial synchrony have been widely used to achieve consistency. In general, chain-based BFT SMR protocols follow the conventional propose-vote paradigm where there exists a special role often called leader who is responsible for packing clients' requests into proposals, and then all players achieve consensus on these proposals via multiple (two or three) phases of voting.
PBFT [9], as the first practical BFT SMR protocol under the partial synchronous network [10], achieves safety even under the asynchronous network and liveness when the network gets synchronous. However, the view-change subprotocol in PBFT, with an O(n) 3 communication complexity, is too heavy to be practical. Tendermint [6] innovatively employs a lock-commit scheme, similar to the paradigm in [11], that a replica should lock on the proposal he has voted COMMIT for. is allows one replica to decide if voting for one proposal according to his own local states and the leader has no need to prove the safety of his proposal. Casper [7,8] takes a similar strategy and also implies a pipelining idea for a further improvement. However, both Tendermint and Casper sacrifice optimistic responsiveness in that there needs to be a fixed interval between proposals to guarantee liveness since a new leader has to ensure that he has observed all other nonfaulty replicas' lock state; otherwise, his new proposal may not be accepted. HotStuff [1] creatively introduces another phase of vote to achieve both linear view-change and optimistic responsiveness. e additional phase guarantees that a new leader can construct this proposal safely only with n − f replicas' states. However, in pipelined HotStuff, the three-phase voting scheme not only brings about an increase in latency but also causes an implicit liveness problem. In pipelined HotStuff, there needs to be four consecutive nonfaulty leaders to make a decision which cannot be guaranteed in the n � 3f + 1 setting. is means pipelined HotStuff cannot provide liveness in the worst case even under the crash fault-tolerant model, which has also been discussed as the silence attack [12].
We present Lodestone, a novel chain-based BFT SMR protocol, which achieves the following combined properties under partial synchrony: (1) Two-phase voting with optimistic responsiveness: Lodestone can achieve responsiveness when liveness is guaranteed after GST. at is, the total time of confirmation on one honest leader's proposal only relies on the actual network delay instead of any apriori upper bound assumption of network delay.

BFT SMR Protocols in Alternative Assumptions.
ere are also many works considering about BFT protocols in alternative assumptions.
Firstly, about the network assumption, many recent protocols under a synchronous network [13][14][15] or under an asynchronous network [16][17][18] make efforts to reduce confirmation latency and achieve practical throughput. Secondly, about the corruption assumption, some recent works [19,20] are aimed to provide higher assurance on blocks even if the adversary corrupts more than f replicas in the future. In this paper, we only concentrate on static security under a partially synchronous network.

Single-Shot BFT Protocols.
ere are some related works [21][22][23] focusing on the single-shot BFT problem which explore the optimal latency bound when the leader is nonfaulty under various resilience assumptions. ough it is still a long way to construct a protocol from single shot to multishots, some results are interesting and may be combined with our protocols in the future work.

View Synchronization.
Another related line of work is about view synchronization [24][25][26] in the partial synchrony setting. It is also necessary in Lodestone for nonfaulty replicas to stay in the same view for a sufficient long time, and then liveness can be guaranteed. However, view synchronization is not the key point of Lodestone, and we assume that replicas are able to stay in the same view for a sufficient long time after GST.

Models
(1) reat model: we consider a permissioned system consisting of n replicas, indexed by i ∈ [n], where [n] � 1, 2, . . . , n { }. We assume a polynomially bounded adversary who can corrupt less than n/3 replicas. e replicas corrupted by the adversary can deviate from the prescribed protocol arbitrarily within their capabilities which are also called Byzantine faulty replicas, while the remaining ones are nonfaulty. We only consider a static corruption model in that the adversary chooses which replicas to corrupt prior to the execution.
(2) Network model: we assume that each pair of replicas is connected by a reliable authenticated point-topoint channel. Messages are propagated through a partially synchronous network [10] in that there is an unknown global stabilization time (GST). After GST, a message sent by a nonfaulty replica will be delivered to all nonfaulty replicas with a known bound Δ, though the delivery schedule is determined by the adversary. (3) Cryptographic primitives: we assume a cryptographic hash function Hash(m) and a standard digital signature scheme. We also assume a (t, n) threshold signature scheme [27,28] which provides the following interfaces: ThresholdSetup(1 λ ) generates a pair of key shares pk i , sk i for replica i along with a global public key PK. ThresholdSign i (m) produces a signature share λ i of message m with sk i . ThresholdVerifyShare(m, i, λ i ) verifies if λ i is a valid signature share of message m. ThresholdCombine(m, i, λ i,i∈I ) produces the threshold signature λ of message m from t signature shares where I ⊂ [n] and |I| � t. ThresholdVerify(m, λ) verifies if λ is a valid threshold signature of message m with PK. We use an (n − f, n) threshold signature scheme in our following protocols which is assumed to provide robustness and nonforgeability. (4) Problem definition: we now give the definition of a chain-based BFT SMR protocol. Each replica in a chain-based BFT SMR protocol receives requests from clients and maintains a sequence of blocks called a blockchain. Blocks in a blockchain are chained by hash digest, and thus, each block in a blockchain has its own position denoted as its height.
Given a blockchain C and a block b ∈ C, all blocks in C lower than b are ancestor blocks of b, and all blocks in C higher than b are descendant blocks of b. Two blocks b 1 and b 2 are conflicting if and only if b 1 is neither an ancestor nor a descendant block of b 2 . Each block includes a batch of requests, and one In the timeout case, nonfaulty replicas who have received b 3 ′ will lock on b 1 but will still vote for b 4 ′ since b 4 ′ also extends from b 1 . replica's blockchain consists of all blocks which have been finalized. Replicas execute requests in finalized blocks in the sequence of the blockchain and then respond to clients. For simplicity, we do not model clients and assume all requests are sent to all replicas. us, we say requests from clients are input to all replicas, and at any time, the output of one replica is his blockchain.
A secure chain-based BFT SMR protocol should satisfy both safety and liveness defined below (in the presence of an arbitrary adversary with all but negligible probability). Definition 1. (safety). At any time, if two nonfaulty replicas each have their blockchains denoted as C 1 and C 2 , then it must be either C 1 ≼C 2 or C 2 ≼C 1 , where ≼ means "is a prefix of or equal to." In other words, two nonfaulty replicas will never finalize different blocks at the same height.
Definition 2. (liveness). If a request req has been inputted to all replicas at time t > T start , then at time t + T confirm , any nonfaulty replica must output a blockchain which includes req, where T start is the time after which the protocol provides liveness and T confirm is a bounded constant.

Preliminaries
(1) Block: we now format a block b in our protocol as b � parent, view, txs, and hash where parent is the hash digest of the parent block of b, view is the view in which b is proposed, txs is a batch of requests from clients, and hash is the hash digest of b (i.e., b.hash � Hash(b.parent, b.view, b.txs)). In Lodestone, there are three states for one block, namely, PROPOSED, PREPARED, and COMMITTED. Once a block reaches the COMMITTED state, then the block itself and its all ancestor blocks are finalized and can be executed sequentially. (2) Local states: replicas in Lodestone need to maintain two local states for the protocol execution. e first denoted as currView represents the current view number and implies the current leader. It is noted that using the round-robin manner to rotate leaders guarantees that (i) the protocol will be greeted with a nonfaulty leader after at most f consecutive views; (ii) there exist three consecutive views of which leaders are all nonfaulty which will be proved later. e second is lockedQC which stores qc with the largest view number one replica has voted commit for. Once a nonfaulty replica locks on qc (i.e., sets lockedQC as qc), he will only vote for blocks extending from block b that Hash(b) � qc.hash unless he ensures the majority of nonfaulty replicas have turned to a conflicting branch before locking on qc.
(3) Promise and promise-set: during a view-change, each replica additionally sends to the leader a promise, evidence that helps the leader locate the highest COMMITTED block and prove that he does so in an honest manner. A promise for view v indicates that the replica has not voted commit at view v.
If n − f replicas send promises for the view v, then there is no block which has a larger view number than v could be COMMITTED. When the leader proposes a block with the n − f promises, all the nonfaulty replicas can accept it safely. A promise from replica P includes a tuple v, v and the corre- from P. We denote p � v, v, σ for simplicity. We say p from P for the current view v represents that he did not vote commit when he was in the view v. Let v be the last view in which P has voted commit. P will generate a set of promises for each view from v + 1 to currView. We denote it as a promise-set. (4) NullQC: before entering a new view, each nonfaulty replica P i will send his promise-set promise-set to the new leader, along with his lockedQC. Upon receiving valid promise-sets from n − f distinct replicas, the new leader will select lockedQC with the largest view number as highQC and propose his new block following the block b where Hash(b) � highQC.hash. Let I be the set of indexes of the n − f replicas; we have |I| � n − f. We use v to denote currView and v to denote highQC.view. Each promise-set must contain a promise that promise v,(v+1) where i ∈ I. e new leader can combine these n − f signature shares as a threshold signature to prove that highQC he selected is exactly the one with the largest view number among n − f replicas. is extra proof is denoted as nullQC in Lodestone. We have

Pipelined Lodestone.
We are now ready to describe our protocol pipelined Lodestone. We first define some utilities as shown in Figure 4. en, we formalize pipelined Lodestone with algorithms. e protocol runs in a succession of views denoted as currView. Each view number is mapped into a leader in a round-robin manner. e leader will execute Algorithm 1, all replicas will execute Algorithm 2, and then the next leader will execute Algorithm 3. When timeout triggers during any wait-for procedure in one replica's local view, he will execute Algorithm 4. We omit any check for brevity.
Proof. For any valid qc, at least n − 2f nonfaulty replicas have sent their relevant signature shares, namely, at least n − 2f nonfaulty replicas have voted for the block which qc.block represents in qc.view. Suppose qc 1 and qc 2 are two valid qc such that qc 1 · view � qc 2 · view, but qc 1 · block ≠ qc 2 · block. We must have that at least n − 2f nonfaulty replicas voted for the qc 1 · block and also at least n − 2f nonfaulty replicas voted for the qc 2 · block in the same view. us, the intersection of the two sets at least includes one nonfaulty replica since 2 × (n − 2f) > n − f, a contradiction to Algorithm 2 that a nonfaulty replica can only vote once in a view. W.l.o.g, we can assume that b 2 · view > b 1 ′ · view with Lemma 1. Since b 1 is COMMITTED, at least n − 2f nonfaulty replicas have voted for b 1' and then locked on b 1 . Let b be the PREPARED block with the smallest view number that satisfies b.view > b 1 ′ .view, and b conflicts with b 1 . Such b must exist since b 2 satisfies all these conditions. Now, consider the proposal m of b. At least n − 2f nonfaulty replicas have locked on b 1 in b 1 ′ · view. ese n − 2f nonfaulty replicas will only promise on view number larger than b 1 · view since then. erefore, m · proof · view > b 1 · view. And due to the minimality of b, we must have m · qc. Proof. Let P i be the nonfaulty leader of view v. If P i collects n − f valid view-change messages, he will select qc with the largest view number among them as highQC. Each of the n − f valid view-change messages must also include a promise on highQC.view + 1; then, P i can combine a threshold signature with these n − f signature shares and construct nullQC that nullQC · view � highQC · view + 1.

Security and Communication Networks
duration T that if all nonfaulty replicas stay in the same view during T, then the leader can propose his new block with nullQC · view � highQC · view + 1 according to Lemma 3. us, the first nonfaulty leader of v will propose a block b, and all nonfaulty replicas will vote for b. en, the second nonfaulty leader of v + 1 will collect n − f votes for b and propose a block b' with highQC ′ · view � v∧ nullQC ′ · view � v + 1. All nonfaulty replicas will also vote for b'. en, the third nonfaulty leader of v + 2 will collect n − f votes for b' and propose a block b'' with highQC ″ .view � v + 1. erefore, b, b', and b'' form a twochain b, b ′ , b ′ , and all nonfaulty replicas will consider b as COMMITTED after receiving b''. For any time t, the three consecutive views leaded by nonfaulty players will come within a bounded time duration after t.
erefore, there exists a bounded constant T confirm in that for any request input to all replicas at time t, it will be included in the finalized block at t + T confirm .

Communication Complexity.
We now discuss the communication complexity of pipelined Lodestone. It is noted that we only consider the communication overhead when liveness can be guaranteed after GST. When the network is asynchronous, there may be unbounded views without making a decision. In fact, we can allow replicas at most send f promises during a view-change which has no effect on the safety property since it is impossible to guarantee liveness under an asynchronous network [29]. Proof. When liveness can be guaranteed after GST, whenever two consecutive views are leaded by nonfaulty replicas, the second leader can generate qc, and all nonfaulty replicas will update their lockedQC. erefore, in the worst case, there are 2f + 1 consecutive views without generating new qc. And then, one replica needs to send 2f + 1 promises on these 2f + 1 views. And thus, the total complexity of a viewchange is O(n 2 ) in the worst case. Now, we discuss the communication complexity of a view-change in the average case. e probability of one view leaded by a faulty replica can be considered as 1/3 while 2/3 by a nonfaulty leader approximately with the assumption n � 3f + 1. Given any view v, let X be the length of views before v without any two consecutive views leaded by nonfaulty replicas. Let P(X) be the probability distribution of X. For any view v, X � k occurs when (i) Either the leader of v − 1 is faulty and X � k − 1 holds for v − 1 (ii) Or the leader of v − 1 is nonfaulty while the leader of v − 2 is faulty and X � k − 2 holds for v − 2 As the assumption, v − 1 and v − 2 also follow the same probability distribution which is denoted as P(X � k − 1) and P(X � k − 2), respectively. en, P(X � k) can be expressed as e expectation E(X) is the length of views before v without any two consecutive views leaded by nonfaulty players on average. E(k) is also the total number of signatures in the promise-set of one replica on average. We have E(X) � 7/4 after simplification. erefore, the expectation of the total communication overhead of a view-change is O(n) for all n replicas in a view.

Implementation and Setup.
We have implemented both pipelined Lodestone and pipelined HotStuff in C++ language with the same codebase for a fair comparison, taking the implementation (https://github.com/hot-stuff/ libhotstuff) in HotStuff's paper [1] as a reference. We use Ed25519 for common digital signatures and BLS threshold signatures (https://github.com/herumi/bls) for combining signatures in our protocol.
We deploy our experiments on Alibaba Cloud using ecs.ic5.4xlarge instances. e round-trip delay between two instances is less than 1 millisecond, with the bandwidth about 5 Gbps.
In all experiments, besides all players and clients, we develop a coordinator who is responsible for notifying all clients sending requests to players. e coordinator collects measurement data to compute the throughput and end-toend latency of clients. Figure 5 shows the architecture in our experiments.
We first evaluate these two protocols with zero-sized payload and different choices of batch sizes to get rid of the effects of payload size. Figure 6 shows that Lodestone has a prominent lower latency compared with HotStuff under the batch size of both 400 and 800 benefiting from conserving one phase of the vote. Figure 7 depicts different payload sizes for both systems as 512 bytes and 1024 bytes, with a fixed batch size of 800. In such settings, Lodestone still enjoys a remarkable lower latency compared with HotStuff and provides comparable throughput.

Conclusions
We presented pipelined Lodestone, a chain-based BFT SMR protocol, which achieves linear view-change on average and optimistic responsiveness with only two phases of voting.
rough the experimental results, pipelined Lodestone provides a lower latency and comparable throughput compared with HotStuff in various workloads and network scales.

Data Availability
e data used to support the findings of this study are available from the corresponding author upon request.