Cogsworth: Byzantine View Synchronization

Abstract

Many distributed protocols in the partial synchrony setting with Byzantine nodes divide the local state of the nodes into views, and the transition from one view to the next dictates a leader change. In order to provide liveness, all honest nodes need to stay in the same view for a sufficiently long time. This requires intricate mechanisms that are typically intertwined with the rest of the protocol, making it hard to understand and to reason about. Furthermore, state-machine replication, which is consisted of multiple instances of single-shot consensus can use the same view synchronization protocol.We define the Byzantine View Synchronization problem, which is responsible for eventually bringing all nodes to the same view for a sufficiently long time.Two approaches for implementing a protocol that achieves view synchronization exhibit the following tradeoffs: a view doubling solution has zero communication costs but unbounded latency, while a broadcastbased solution has quadratic communication costs but constant latency. We describe both protocols, prove their correctness, and also introduce a third protocol, named Lumière 1 , that has optimistically linear communication complexity and constant latency, and faced with benign failures, has expected linear communication and constant latency. Lumière is particularly useful for a family of consensus protocols that exhibit linear communication under various circumstances.

Dissecting the Performance of Chained-BFT

“…Note that the Pacemaker module causes quadratic message complexity even though HotStuff has linear message complexity in the happy path. Other proposals such as Cogsworth [18] present optimized solutions that have reduced message complexity and constant latency, which will be considered in future work.…”

Be Aware of Your Leaders

“…The Pacemaker [4,15,16] component is a commonly used abstraction, which ensures that, after GST, parties are synchronized and participate in the same round long enough to satisfy the LBR progress. We assume the following: Definition 3 (Pacemaker).…”

“…Note that by using the above definition, the resulting protocol is not responsive since parties wait ∆ p before advancing rounds. This can easily be fixed by using a more general Pacemaker definitions from [4,15,16]. However, we chose the simplified version above for readability purposes since the Pacemaker is orthogonal to the thesis of our paper.…”

“…To focus on our leader-rotation mechanism, we abstract away all other SMR components by defining an SMR framework. Similarly to [19], we capture the logic and properties of forming and certifying blocks of transactions in each round in a Leader-based round (LBR) abstraction, and rely on a Pacemaker abstraction [4,15,16] for round synchronization. We prove that when instantiated into this framework, Carousel yields a Leader-Aware SMR protocol.…”

Quadratic worst-case message complexity for State Machine Replication in the partial synchrony model

“…The task of achieving a general and efficient implementation of the Pacemaker module is addressed in a couple of recent papers by Naor et. al [NBMS19]. and Naor and Keidar[NK20].…”