Searcharxiv⌕ Search

arXiv subjects

Mohammad M. Jalalzai

Publications and source records attributed to Mohammad M. Jalalzai.

10 recordsLinked to original sources

TreePIR: Efficient Private Retrieval of Merkle Proofs via Tree Colorings with Fast Indexing and Zero Storage Overhead

A Batch Private Information Retrieval (batch-PIR) scheme allows a client to retrieve multiple data items from a database without revealing them to the storage server(s). Most existing approaches for batch-PIR are based on batch codes, in particular, probabilistic batch codes (PBC) (Angel et al. S&P'18), which incur large storage overheads. In this work, we show that \textit{zero} storage overhead is achievable for tree-shaped databases. In particular, we develop TreePIR, a novel approach tailored made for private retrieval of the set of nodes along an arbitrary root-to-leaf path in a Merkle tree with no storage redundancy. This type of trees has been widely implemented in many real-world systems such as Amazon DynamoDB, Google's Certificate Transparency, and blockchains. Tree nodes along a root-to-leaf path forms the well-known Merkle proof. TreePIR, which employs a novel tree coloring, outperforms PBC, a fundamental component in state-of-the-art batch-PIR schemes (Angel et al. S&P'18, Mughees-Ren S&P'23, Liu et al. S&P'24), in all metrics, achieving $3\times$ lower total storage and $1.5$-$2\times$ lower computation and communication costs. Most notably, TreePIR has $8$-$160\times$ lower setup time and its polylog-complexity indexing algorithm is $19$-$160\times$ faster than PBC for trees of $2^{10}$-$2^{24}$ leaves.

cs.DS↗

VBFT: Veloce Byzantine Fault Tolerant Consensus for Blockchains

Low latency is one of the most desirable features of partially synchronous Byzantine consensus protocols. Existing low-latency protocols have achieved consensus with just two communication steps by reducing the maximum number of faults the protocol can tolerate (from $f = \frac{n-1}{3}$ to $f = \frac{n+1}{5}$), \textcolor{black}{by relaxing protocol safety guarantees}, or by using trusted hardware like Trusted Execution Environment. Furthermore, these two-step protocols don't support rotating leaders and low-cost view change (leader replacement), which are important features of many blockchain use cases. In this paper, we propose a protocol called VBFT which achieves consensus in just two communication steps without sacrificing desirable features. In particular, VBFT tolerates $f = \frac{n-1}{3}$ faults (which is the best possible), guarantees strong safety for honest leaders, and requires no trusted hardware. Moreover, VBFT supports leader rotation and low-cost view change, thereby improving prior art on multiple axes.

cs.DC↗

Carnot: A highly Scalable and Responsive BFT Consensus protocol

We present Carnot, a leader-based Byzantine Fault Tolerant (BFT) consensus protocol that is responsive and operates under the partially synchronous model. Responsive BFT consensus protocols exhibit wire-speed operation and deliver instantaneous finality, thereby addressing a fundamental need in distributed systems. A key challenge in scaling these protocols has been the computational complexity associated with authenticator verification. We demonstrate that Carnot effectively addresses this bottleneck by adeptly streamlining the verification and aggregation of $O(log(N))$ authenticators per node. This notable advancement marks a substantial improvement over the prevailing $O(N)$ state-of-the-art approaches. Leveraging this inherent property, Carnot demonstrates its capacity to seamlessly scale to networks comprising tens to hundreds of thousands of nodes. We envision Carnot as a critical stride towards bridging the gap between classical BFT consensus mechanisms and blockchain technology.

cs.DC↗

How to generate a fault-resilient network at a lower cost

Blockchains facilitate decentralization, security, identity, and data management in cyber-physical systems. However, consensus protocols used in blockchains are prone to high message and computational complexity costs and are not suitable to be used in IoT. One way to reduce message complexity is to randomly assign network nodes into committees or shards. Keeping committee sizes small is then desirable in order to achieve lower message complexity, but this comes with a penalty of reduced reliability as there is a higher probability that a large number of faulty nodes will end up in a committee. In this work, we study the problem of estimating a probability of a failure in randomly sharded networks. We provide new results and improve existing bounds on the failure probability. Thus, our framework also paves the way to reduce committee sizes without reducing reliability.

cs.DC↗

Fast-HotStuff: A Fast and Resilient HotStuff Protocol

The HotStuff protocol is a breakthrough in Byzantine Fault Tolerant (BFT) consensus that enjoys both responsiveness and linear view change. It creatively adds an additional round to classic BFT protocols (like PBFT) using two rounds. This brings us to an interesting question: Is this additional round really necessary in practice? In this paper, we answer this question by designing a new two-round BFT protocol called Fast-HotStuff, which enjoys responsiveness and efficient view change that is comparable to linear view change in terms of performance. Compared to (three-round) HotStuff, Fast-HotStuff has lower latency and is more robust against performance attacks that HotStuff is susceptible to.

cs.DC↗

Fast B4B: Fast BFT for Blockchains

Low latency is one of the desired properties for partially synchronous Byzantine consensus protocols. Previous protocols have achieved consensus with just two communication steps either by reducing the bound on the number of faults the protocol can tolerate ($f \leq \frac{n-1}{5}$) or use of trusted hardware like Trusted Execution Environment or TEEs. In this paper, we propose a protocol called Fast B4B, in which the protocol achieves consensus in just two communication steps. Fast B4B can tolerate maximum number of faults a partial BFT consensus can tolerate ($f \leq \frac{n-1}{3}$). Furthermore, Fast B4B does not require the use of any trusted hardware. The trade-off for this achievement is that at most $f$ times some nodes may revert their blocks. We show that this reversion of a block will not compromise the safety of the protocol at all, yet it may incur a small amount of additional latency during view change.

cs.DC↗

On the Performance of Pipelined HotStuff

HotStuff is a state-of-the-art Byzantine fault-tolerant consensus protocol. It can be pipelined to build large-scale blockchains. One of its variants called LibraBFT is adopted in Facebook's Libra blockchain. Although it is well known that pipelined HotStuff is secure against up to $1/3$ of Byzantine nodes, its performance in terms of throughput and delay is still under-explored. In this paper, we develop a multi-metric evaluation framework to quantitatively analyze pipelined \mbox{HotStuff's performance} with respect to its chain growth rate, chain quality, and latency. We then propose two attack strategies and evaluate their effects on the performance of pipelined HotStuff. Our analysis shows that the chain growth rate (resp, chain quality) of pipelined HotStuff under our attacks can drop to as low as 4/9 (resp, 12/17) of that without attacks when $1/3$ nodes are Byzantine. As another application, we use our framework to evaluate certain engineering optimizations adopted by LibraBFT. We find that these optimizations make the system more vulnerable to our attacks than the original pipelined HotStuff. Finally, we provide two countermeasures to thwart these attacks. We hope that our studies can shed light on the rigorous understanding of the state-of-the-art pipelined HotStuff protocol as well as its variants.

cs.DC↗

The Hermes BFT for Blockchains

The performance of partially synchronous BFT-based consensus protocols is highly dependent on the primary node. All participant nodes in the network are blocked until they receive a proposal from the primary node to begin the consensus process.Therefore, an honest but slack node (with limited bandwidth) can adversely affect the performance when selected as primary. Hermes decreases protocol dependency on the primary node and minimizes transmission delay induced by the slack primary while keeping low message complexity and latency. Hermes achieves these performance improvements by relaxing strong BFT agreement (safety) guarantees only for a specific type of Byzantine faults (also called equivocated faults). Interestingly, we show that in Hermes equivocating by a Byzantine primary is unlikely, expensive and ineffective. Therefore, the safety of Hermes is comparable to the general BFT consensus. We deployed and tested Hermes on 190 Amazon EC2 instances. In these tests, Hermes's performance was comparable to the state-of-the-art BFT protocol for blockchains (when the network size is large) in the absence of slack nodes. Whereas, in the presence of slack nodes Hermes out performed the state-of-the-art BFT protocol by more than 4x in terms of throughput as well as 15x in terms of latency.

cs.DC↗

Window Based BFT Blockchain Consensus

There is surge of interest to the blockchain technology not only in the scientific community but in the business community as well. Proof of Work (PoW) and Byzantine Fault Tolerant (BFT) are the two main classes of consensus protocols that are used in the blockchain consensus layer. PoW is highly scalable but very slow with about 7 (transactions/second) performance. BFT based protocols are highly efficient but their scalability are limited to only tens of nodes. One of the main reasons for the BFT limitation is the quadratic $O(n^2)$ communication complexity of BFT based protocols for $n$ nodes that requires $n \times n$ broadcasting. In this paper, we present the {\em Musch} protocol which is BFT based and provides communication complexity $O(f n + n)$ for $f$ failures and $n$ nodes, where $f < n/3$, without compromising the latency. Hence, the performance adjusts to $f$ such that for constant $f$ the communication complexity is linear. Musch achieves this by introducing the notion of exponentially increasing windows of nodes to which complains are reported, instead of broadcasting to all the nodes. To our knowledge, this is the first BFT-based blockchain protocol which efficiently addresses simultaneously the issues of communication complexity and latency under the presence of failures.

cs.DC↗

Proteus: A Scalable BFT Consesus Protocol for Blockchains

Byzantine Fault Tolerant (BFT) consensus exhibits higher throughput in comparison to Proof of Work (PoW) in blockchains. But BFT-based protocols suffer from scalability problems with respect to the number of replicas in the network. The main reason for this limitation is the quadratic message complexity of BFT protocols. Previously, proposed solutions improve BFT performance for normal operation, but will fall back to quadratic message complexity once the protocol observes a certain number of failures. This makes the protocol performance unpredictable as it is not guaranteed that the network will face a a certain number of failures. As a result, such protocols are only scalable when conditions are favorable (i.e., the number of failures are less than a given threshold). To address this issue we propose Proteus, a new BFT-based consensus protocol which elects a subset of nodes $c$ as a root committee. Proteus guarantees stable performance, regardless of the number of failures in the network and it improves on the quadratic message complexity of typical BFT-based protocols to $O(cn)$, where $c<<n$, for large $n$. Thus, message complexity remains small and less than quadratic when $c$ is asymptotically smaller than $n$, and this helps the protocol to provide stable performance even during the view change process (change of root committee). Our view change process is different than typical BFT protocols as it replaces the whole root committee compared to replacing a single primary in other protocols. We deployed and tested our protocol on $200$ Amazon $EC2$ instances, with two different baseline BFT protocols (PBFT and Bchain) for comparison. In these tests, our protocol outperformed the baselines by more than $2\times$ in terms of throughput as well as latency.

cs.DC↗