Resource-Efficient Byzantine Fault Tolerance

Distler, Tobias; Cachin, Christian; Kapitza, Rüdiger

doi:10.1109/tc.2015.2495213

Cited by 89 publications

(55 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To address the security issues in private Blockchains, several variants of PBFT protcol have been proposed. Those protocols try to increase the fault tolerance beyond 33% [154], [155] and use hardware assistance to detect the behavior of faulty replicas [156]. The key challenge in private Blockchains is the high message complexity that restricts the scalability.…”

Section: H Countering Peer-to-peer Attacksmentioning

confidence: 99%

Exploring the Attack Surface of Blockchain: A Comprehensive Survey

Saad

Spaulding

Njilla

et al. 2020

IEEE Commun. Surv. Tutorials

254

161

View full text Add to dashboard Cite

In this paper, we systematically explore the attack surface of the Blockchain technology, with an emphasis on public Blockchains. Towards this goal, we attribute attack viability in the attack surface to 1) the Blockchain cryptographic constructs, 2) the distributed architecture of the systems using Blockchain, and 3) the Blockchain application context. To each of those contributing factors, we outline several attacks, including selfish mining, the 51% attack, Domain Name System (DNS) attacks, distributed denial-of-service (DDoS) attacks, consensus delay (due to selfish behavior or distributed denial-of-service attacks), Blockchain forks, orphaned and stale blocks, block ingestion, wallet thefts, smart contract attacks, and privacy attacks. We also explore the causal relationships between these attacks to demonstrate how various attack vectors are connected to one another. A secondary contribution of this work is outlining effective defense measures taken by the Blockchain technology or proposed by researchers to mitigate the effects of these attacks and patch associated vulnerabilities.

show abstract

Section: H Countering Peer-to-peer Attacksmentioning

confidence: 99%

Exploring the Attack Surface of Blockchain: A Comprehensive Survey

Saad

Spaulding

Njilla

et al. 2020

IEEE Commun. Surv. Tutorials

254

161

View full text Add to dashboard Cite

show abstract

“…Our system (not being synchronous) can tolerate at maximum f = n−1 3 Byzantine processes. Such an f is proved to be the maximum number of Byzantine processes that an asynchronous system with n processes can tolerate to implement any form of agreement [17], [24]. f is known to the processes.…”

Section: B Threat Model A) Clocksmentioning

confidence: 99%

<italic>RT-ByzCast</italic>: Byzantine-Resilient Real-Time Reliable Broadcast

Kozhaya

Decouchant

Esteves-Veríssimo

2019

IEEE Trans. Comput.

View full text Add to dashboard Cite

Today's cyber-physical systems face various impediments to achieving their intended goals, namely, communication uncertainties and faults, relative to the increased integration of networked and wireless devices, hinder the synchronism needed to meet real-time deadlines. Moreover, being critical, these systems are also exposed to significant security threats. This threat combination increases the risk of physical damage. This paper addresses these problems by studying how to build the first real-time Byzantine reliable broadcast protocol (RTBRB) tolerating network uncertainties, faults, and attacks. Previous literature describes either real-time reliable broadcast protocols, or asynchronous (non real-time) Byzantine ones.We first prove that it is impossible to implement RTBRB using traditional distributed computing paradigms, e.g., where the error/failure detection mechanisms of processes are decoupled from the broadcast algorithm itself, even with the help of the most powerful failure detectors. We circumvent this impossibility by proposing RT-ByzCast, an algorithm based on aggregating digital signatures in a sliding time-window and on empowering processes with self-crashing capabilities to mask and bound losses. We show that RT-ByzCast (i) operates in real-time by proving that messages broadcast by correct processes are delivered within a known bounded delay, and (ii) is reliable by demonstrating that correct processes using our algorithm crash themselves with a negligible probability, even with message loss rates as high as 60%.

show abstract

“…The TEE's integrity can be remotely attested. We therefore assume a hybrid fault model [14], [15], [16], [17], [18], [19], [20]: the ordering service can be Byzantine, whereas all BLOXIES in the system are assumed to behave as expected or fail only by crashing. Nodes can therefore trust the correctness of the block if they receive it from a BLOXY over a secure channel.…”

Section: B System Model and Trusted Subsystemmentioning

confidence: 99%

“…It overcomes the challenges that BFT protocols such as BFT-SMART face: (i) We offer full modularity by transparently encapsulating all client functionality inside the BLOXY. (ii) We rely on a trusted subsystem that can only fail by crashing, thereby relaxing the Byzantine fault model to a hybrid one [14], [15], [16], [17], [18], [19], [20], thus allowing us to have trusted client functionality on BFT replicas. BLOXY is running inside a trusted execution environment (TEE) based on Intel's Software Guard Extensions (SGX).…”

Section: Introductionmentioning

confidence: 99%

Bloxy: Providing Transparent and Generic BFT-Based Ordering Services for Blockchains

Rüsch

Bleeke

Kapitza

2019

2019 38th Symposium on Reliable Distributed Systems (SRDS)

Self Cite

View full text Add to dashboard Cite

With the wide-spread use of blockchain technology, Byzantine fault-tolerant (BFT) protocols are explored as a means to achieve consensus on which transactions should be processed next. BFT protocols are not a one-size-fits-all solution: they should be chosen according to the blockchain's use case, which can range from supply chain management to decentralised storage, requiring specialisation e. g. regarding throughput, latency, or level of decentralisation. Previously, consensus protocols were usually hardcoded into the blockchain infrastructure and could not be exchanged, therefore inhibiting flexible use of an otherwise generic blockchain infrastructure. Hyperledger Fabric claims to provide modular consensus and support for crash-fault and Byzantine fault tolerant protocols. However, integrating a BFT protocol has shown that Fabric's architecture is currently not well-suited for this fault model as it requires substantial changes and thereby breaks Fabric's modularity. This also has to be repeated for each integrated BFT protocol.In this paper, we present BLOXY, a blockchain-aware trusted proxy running on the replica that encapsulates all BFT client functionality. BLOXY enables transparent access to generic BFT frameworks and preserves Fabric's modularity even for the Byzantine fault model. It runs inside a trusted execution environment based on Intel's Software Guard Extensions. BLOXY offers blockchain-specific communication mechanisms as well as short-term block storage to handle crashes or disconnects to ensure that all nodes receive block updates. We implemented two BLOXY-based ordering services based on PBFT and the hybrid BFT protocol Hybster. Our evaluation shows that our approach increases the throughput of the ordering component by up to 71 % compared to directly integrated BFT protocols.

show abstract

Resource-Efficient Byzantine Fault Tolerance

Cited by 89 publications

References 23 publications

Exploring the Attack Surface of Blockchain: A Comprehensive Survey

Exploring the Attack Surface of Blockchain: A Comprehensive Survey

<italic>RT-ByzCast</italic>: Byzantine-Resilient Real-Time Reliable Broadcast

Bloxy: Providing Transparent and Generic BFT-Based Ordering Services for Blockchains

Contact Info

Product

Resources

About