Abstract
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 BFT protocols, Lodestone can be optimized with a pipelining idea elegantly. We implement pipelined Lodestone and deploy experiments to evaluate its performance. The evaluation results demonstrate that Lodestone has a lower latency than HotStuff under various workloads.
Highlights
Consensus in blockchain systems, known as state machine replication (SMR), has attracted more and more interest in recent years
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
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 been discussed as the silence attack [12]
Summary
Known as state machine replication (SMR), has attracted more and more interest in recent years. 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 all players achieve consensus on these proposals via multiple (two or three) phases of voting. Casper [7, 8] takes a similar strategy and implies a pipelining idea for a further improvement 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 difference in detail between these protocols can be shown in figures, of which Figures 1 and 2 show HotStuff and existing two-phase voting protocols, respectively, while Figure 3 demonstrates our solution
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
