Multi-valued Byzantine Broadcast: The t &lt; n Case

Hirt, Martin; Raykov, Pavel

doi:10.1007/978-3-662-45608-8_24

Cited by 17 publications

(10 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Being a classic distributed computing problem, byzantine broadcast has been extensively studied. We will only focus on byzantine broadcast protocols [6], [8], [9], [14], [24], [30], [31] that can tolerate f ≥ 1 2 . Most of these are actually theoretical designs without implementation.…”

Section: Related Workmentioning

confidence: 99%

“…Section I and III already discussed [6], [8], [30]. The protocols from [9], [14], [24] all require direct point-to-point communication on a clique, and hence does not work for multi-hop topologies. Furthermore, these protocols are designed for a permissioned setting with a fixed set of n nodes.…”

Section: Related Workmentioning

confidence: 99%

“…Furthermore, these protocols are designed for a permissioned setting with a fixed set of n nodes. The following nevertheless still reviews the techniques used in [9], [14], [24], and characterizes their TTB ratios.…”

Section: Related Workmentioning

confidence: 99%

“…But at the same time, the resulting blockchain's throughput will also inherit from the throughput of the byzantine broadcast protocol. This turns out to be the major obstacle, because existing byzantine broadcast proto-cols [6], [8], [9], [14], [24], [30], [31] seriously fall short of providing acceptable throughput, as shown next. Throughput of existing byzantine broadcast protocols.…”

Section: Introductionmentioning

confidence: 98%

“…In our pursuit of blockchains that can tolerate f ≥ 1 2 , we have revisited various classical primitives. We eventually focus on one such primitive -byzantine broadcast [6], [8], [9], [14], [24], [30], [31]. In byzantine broadcast, there is a single publicly known broadcaster that broadcasts an object (e.g., a block in blockchain) to all nodes.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Using Throughput-Centric Byzantine Broadcast to Tolerate Malicious Majority in Blockchains

Hou¹,

Yu²,

Saxena³

2021

Preprint

View full text Add to dashboard Cite

Fault tolerance of a blockchain is often characterized by the fraction f of "adversarial power" that it can tolerate in the system. Despite the fast progress in blockchain designs in recent years, existing blockchain systems can still only tolerate f below 1 2 . Can practically usable blockchains tolerate a malicious majority, i.e., f ≥ 1 2 ? This work presents a positive answer to this question. We first note that the well-known impossibility of byzantine consensus under f ≥ 1 2 does not carry over to blockchains. To tolerate f ≥ 1 2 , we use byzantine broadcast, instead of byzantine consensus, as the core of the blockchain. A major obstacle in doing so, however, is that the resulting blockchain may have extremely low throughput. To overcome this central technical challenge, we propose a novel byzantine broadcast protocol OVERLAYBB, that can tolerate f ≥ 1 2 while achieving good throughput. Using OVERLAYBB as the core, we present the design, implementation, and evaluation of a novel Proof-of-Stake blockchain called BCUBE. BCUBE can tolerate a malicious majority, while achieving practically usable transaction throughput and confirmation latency in our experiments with 10000 nodes and under f = 0.7. To our knowledge, BCUBE is the first blockchain that can achieve such properties.1 A similar requirement has led to the recent impossibility result in [10].

show abstract