http://lodlaundromat.org/17714688a41ffdc6c4b8d6d6fe627c4f
creator: ReSIST Project
source: resilience-mechanism-65b5cef4
created: 2015-02-09T03:41:40
coreference data: resilience-mechanism-65b5cef4
type: Ontology

resilience-mechanism-65b5cef4
addresses-threat-to-resilience: Non-Deliberate-Fault
addressess-generic-area-of-interest: Non-Malicious-Fault
relates-to-new-wg: resist wg divers
addressess-generic-area-of-interest: Availability
addressess-generic-area-of-interest: Reliability
has-application-domain: J.2.5
has-application-domain: J.2.0
addresses-threat-to-resilience: Permanent-Fault
has-related-mechanism: id
has-application-domain: J.3.2
addresses-threat-to-resilience: Transient-Fault
has-mechanism-category: mechanism-category-5c57c5d5
has-title: BFT - Practical Byzantine Fault Tolerance
has-related-mechanism: resilience-mechanism-59726624
addresses-threat-to-resilience: Hardware-Fault
addresses-threat-to-resilience: Malicious-Fault
addresses-threat-to-resilience: Accidental-Fault
has-application-domain: J.7.4
addresses-threat-to-resilience: Software-Fault
addresses-threat-to-resilience: Human-Made-Fault
addresses-threat-to-resilience: Development-Fault
addresses-threat-to-resilience: Omission-Fault
addresses-threat-to-resilience: Content-And-Timing-Failure
has-application-domain: J.1.0
has-mechanism-category: mechanism-category-cc11ff2f
addressess-generic-area-of-interest: Inconsistent-Failures
addresses-threat-to-resilience: Timing-Failure
has-component: technology-830ab2bf
addressess-generic-area-of-interest: Inconsistent-Error
has-related-mechanism: resilience-mechanism-ca383a29
relates-to-concept: resilience-concept-45a75e44
addresses-threat-to-resilience: Unsignalled-Failure
addressess-generic-area-of-interest: Robustness
addressess-generic-area-of-interest: Compensation
has-component: technology-5f6756ea
has-knowledge-requirement: knowledge-5f6756ea
addressess-generic-area-of-interest: Content-Error
has-application-domain: J.1.3
relates-to-concept: resilience-concept-c7c29966
has-mechanism-category: Resilience-Architecture
addressess-generic-area-of-interest: Fault-Masking
addressess-generic-area-of-interest: Consistent-Error
has-associated-project: resist
relates-to-concept: resilience-concept-5ea14f41
has-component: technology-29334252
addressess-generic-area-of-interest: Single-Error
has-application-domain: J.2.6
addressess-generic-area-of-interest: Timing-Error
applies-to-technology: technology-bc9403e1
relates-to-old-wg: resist wg algo
has-component: technology-87fd6ba4
has-additional-requirements: The mechanism needs to make a synchrony assumption in order to provide liveness; otherwise it could be used to implement consensus in an asynchronous system, which is not possible. Liveness is guaranteed, i.e., clients eventually receive replies to their requests, provided at most floor((n-1)/3) replicas are faulty and delay(t) does not grow faster than t indefinitely. Here, delay(t) is the time between the moment t when a message is sent for the first time and the moment when it is received by its destination (assuming the sender keeps retransmitting the message until it is received). This is a rather weak synchrony assumption that is likely to be true in any real system provided network faults are eventually repaired, yet it enables the mechanism to circumvent the impossibility result.
addresses-threat-to-resilience: Deliberate-Fault
type: Resilience-Mechanism
addresses-threat-to-resilience: Halt-Failure
detailed-description-pub: resource-CS184040
addresses-threat-to-resilience: Non-Malicious-Fault
diversity-comment: In order to cope with Byzantine failure modes, a consensus-based system requires 3m+1 replicas in order to tolerate m independent faults. Various forms of diversity and replication can be used to ensure that faults are independent, depending on the fault hypothesis, but in the worst case, both software and hardware diversity is needed in order to cope with malicious faults.
addressess-generic-area-of-interest: Malicious-Fault
has-application-domain: J.7.2
relates-to-concept: resilience-concept-b6fb8914
has-application-domain: J.3.1
relates-to-concept: resilience-concept-3df9b5c7
has-application-domain: J.7.0
has-component: technology-1731f1ce
mechanism-objectives: A practical implementation of Byzantine Fault Tolerance that can be used in asynchronous environments like the Internet. The mechanism guarantees safety, but needs to make a weak synchrony assumption in order to guarantee liveness.
has-application-domain: J.7.6
addresses-threat-to-resilience: Inconsistent-Failures
addresses-threat-to-resilience: Incompetence-Fault
has-knowledge-requirement: knowledge-597e821d
has-knowledge-requirement: knowledge-a41bb914
has-component: technology-bc9403e1
addressess-generic-area-of-interest: Concurrent-Detection
submitted-by: robert stroud
addresses-threat-to-resilience: Consistent-Failures
detailed-description: This paper describes a new replication algorithm that is able to tolerate Byzantine faults. We believe that Byzantine-fault-tolerant algorithms will be increasingly important in the future because malicious attacks and software errors are increasingly common and can cause faulty nodes to exhibit arbitrary behavior. Whereas previous algorithms assumed a synchronous system or were too slow to be used in practice, the algorithm described in this paper is practical: it works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude. We implemented a Byzantine-fault-tolerant NFS service using our algorithm and measured its performance. The results show that our service is only 3% slower than a standard unreplicated NFS.
addressess-generic-area-of-interest: Integrity