ﻻ يوجد ملخص باللغة العربية
Byzantine fault-tolerant (BFT) state machine replication (SMR) has been studied for over 30 years. Recently it has received more attention due to its application in permissioned blockchain systems. A sequence of research efforts focuses on improving the commit latency of the SMR protocol in the common good case, including PBFT with $3$-round latency and $ngeq 3f+1$ and FaB with $2$-round latency and $ngeq 5f+1$. In this paper, we propose an authenticated protocol that solves $2$-round BFT SMR with only $ngeq 5f-1$ replicas, which refutes the optimal resiliency claim made in FaB for needing $n geq 5f+1$ for $2$-round PBFT-style BFT protocols. For the special case when $f=1$, our protocol needs only $4$ replicas, and strictly improves PBFT by reducing the latency by one round (even when one backup is faulty).
We present new protocols for Byzantine state machine replication and Byzantine agreement in the synchronous and authenticated setting. The celebrated PBFT state machine replication protocol tolerates $f$ Byzantine faults in an asynchronous setting us
This paper presents a novel leaderless protocol (FPC-BI: Fast Probabilistic Consensus within Byzantine Infrastructures) with a low communicational complexity and which allows a set of nodes to come to a consensus on a value of a single bit. The paper
Partially synchronous Byzantine consensus protocols typically structure their execution into a sequence of views, each with a designated leader process. The key to guaranteeing liveness in these protocols is to ensure that all correct processes event
In this paper, we give a deterministic two-step Byzantine consensus protocol that achieves safety and liveness. A two-step Byzantine consensus protocol only needs two communication steps to commit in the absence of faults. Most two-step Byzantine con
In this note, we observe a safety violation in Zyzzyva and a liveness violation in FaB. To demonstrate these issues, we require relatively simple scenarios, involving only four replicas, and one or two view changes. In all of them, the problem is manifested already in the first log slot.