Table of Contents
Fetching ...

Arma: Byzantine Fault Tolerant Consensus with Horizontal Scalability

Yacov Manevich, Hagar Meir, Kaoutar Elkhiyaoui, Yoav Tock, May Buzaglo

TL;DR

Arma addresses the throughput bottlenecks of traditional BFT by decoupling data dissemination/validation from the consensus layer and distributing work across shards within multiple parties. It introduces batchers and assemblers that generate and reconstruct blocks from batch attestations, with censorship resistance and transaction deduplication achieved via probabilistic verification and complaint-based primary batcher rotation. The approach yields horizontal scalability and significantly enhances performance, as demonstrated by prototypes embedded in Hyperledger Fabric and a fully distributed LAN/WAN deployment, while maintaining finality guarantees through a BFT consensus on batch attestations. This work provides a practical path to high-throughput, censorship-resistant, distributed consensus suitable for enterprise blockchains and payment-like applications, with measurable gains over prior multi-instance BFT designs.

Abstract

Arma is a Byzantine Fault Tolerant (BFT) consensus system designed to achieve horizontal scalability across all hardware resources: network bandwidth, CPU, and disk I/O. As opposed to preceding BFT protocols, Arma separates the dissemination and validation of client transactions from the consensus process, restricting the latter to totally ordering only metadata of batches of transactions. This separation enables each party to distribute compute and storage resources for transaction validation, dissemination and disk I/O among multiple machines, resulting in horizontal scalability. Additionally, Arma ensures censorship resistance by imposing a maximum time limit on the inclusion of client transactions. We built and evaluated two Arma prototypes. The first is an independent system handling over 200,000 transactions per second, the second integrated into Hyperledger Fabric, speeding its consensus by an order of magnitude.

Arma: Byzantine Fault Tolerant Consensus with Horizontal Scalability

TL;DR

Arma addresses the throughput bottlenecks of traditional BFT by decoupling data dissemination/validation from the consensus layer and distributing work across shards within multiple parties. It introduces batchers and assemblers that generate and reconstruct blocks from batch attestations, with censorship resistance and transaction deduplication achieved via probabilistic verification and complaint-based primary batcher rotation. The approach yields horizontal scalability and significantly enhances performance, as demonstrated by prototypes embedded in Hyperledger Fabric and a fully distributed LAN/WAN deployment, while maintaining finality guarantees through a BFT consensus on batch attestations. This work provides a practical path to high-throughput, censorship-resistant, distributed consensus suitable for enterprise blockchains and payment-like applications, with measurable gains over prior multi-instance BFT designs.

Abstract

Arma is a Byzantine Fault Tolerant (BFT) consensus system designed to achieve horizontal scalability across all hardware resources: network bandwidth, CPU, and disk I/O. As opposed to preceding BFT protocols, Arma separates the dissemination and validation of client transactions from the consensus process, restricting the latter to totally ordering only metadata of batches of transactions. This separation enables each party to distribute compute and storage resources for transaction validation, dissemination and disk I/O among multiple machines, resulting in horizontal scalability. Additionally, Arma ensures censorship resistance by imposing a maximum time limit on the inclusion of client transactions. We built and evaluated two Arma prototypes. The first is an independent system handling over 200,000 transactions per second, the second integrated into Hyperledger Fabric, speeding its consensus by an order of magnitude.
Paper Structure (41 sections, 5 theorems, 12 figures, 4 algorithms)

This paper contains 41 sections, 5 theorems, 12 figures, 4 algorithms.

Key Result

Lemma 1

If $F+1$ correct parties in a shard receive a transaction $tx$ but a primary batcher in that shard does not include it in a batch, then a different node becomes the primary for that shard.

Figures (12)

  • Figure 1: (a) Multi-Instance BFT vs (b) Distributed Multi-Instance BFT
  • Figure 2: Information flow among components run by a single party. Each party runs several (R)outer nodes, (B)atcher nodes (where each batcher node is mapped to a shard), a single (C)onsensus node and at least one (A)ssembler node. (R)outer nodes dispatches transactions submitted by clients to the shards via their (B)atcher nodes. The (B)atcher nodes send votes on persisted batches to the (C)onsensus nodes for ordering. The (A)ssembler node receives from the (C)onsensus node ordered signatures over the digests of batches persisted by the (B)atcher nodes. The (A)ssembler node then outputs the blocks which consists of the ordered batches and the signatures over their digests.
  • Figure 3: A birds eye view of router and batcher nodes of all parties (a) routing a transaction to the appropriate shard, and (b) broadcasting transaction batches
  • Figure 4: Primary batcher
  • Figure 5: Arma components blue integrated alongside Fabric components (green) in a Fabric ordering node process. Transactions from clients are verified by router nodes and are forwarded into the ordering service node, where the $R^*$ router dispatches them to the batcher instances of appropriate shards.
  • ...and 7 more figures

Theorems & Definitions (12)

  • Definition 1: Nodes
  • Definition 2: Parties
  • Definition 3: Byzantine node/party
  • Definition 4: Quorum
  • Definition 5: Shard
  • Definition 6: Batch
  • Definition 7: Batch Attestation Share (BAS)
  • Lemma 1: Primary rotation
  • Theorem 2: Termination
  • Theorem 3: Agreement
  • ...and 2 more