[Paper Review] Evaluating the Red Belly Blockchain

Crain, Tyler, Natoli, Christopher+1 more|arXiv (Cornell University)|Dec 31, 2018

Blockchain Technology Applications and Security34 references27 citations

TL;DR

The Red Belly Blockchain (RBBC) is a deterministic, Byzantine fault-tolerant blockchain that achieves high throughput and low latency through novel sharding of proposers and verifiers. By distributing transaction proposal and signature verification work across multiple nodes, RBBC scales to 1,000 nodes across 14 datacenters, reaching 660,000 transactions per second with 3-second finality—outperforming traditional BFT and randomized alternatives in both throughput and latency.

ABSTRACT

In this paper, we present the most extensive evaluation of blockchain system to date. To achieve scalability across servers in more than 10 countries located on 4 different continents, we drastically revisited Byzantine fault tolerant blockchains and verification of signatures. The resulting blockchain, called the Red Belly Blockchain (RBBC), commits more than a hundred thousand transactions issued by permissionless nodes. These transactions are grouped into blocks within few seconds through a partially synchronous consensus run by permissioned nodes. It prevents double spending by guaranteeing that a unique block is decided at any given index of the chain in a deterministic way by all participants. We compared the performance of RBBC against traditional Byzantine fault tolerant alternatives and more recent randomized solutions. In the same geo-distributed environment with low-end machines, we noticed two interesting comparisons: (i) the RBBC throughput scales to hundreds of machines whereas the classic 3-step leader-based BFT state machine used by consortium blockchains cannot scale to 40 identically configured nodes; (ii) RBBC guarantees transaction finality in 3 seconds and experiences a third of the latency that randomized-based solutions like HoneyBadgerBFT can offer. This empirical evaluation demonstrates that blockchain scalability can be achieved without sacrificing security.

Motivation & Objective

• To address the scalability limitations of existing Byzantine fault-tolerant blockchains, which typically peak at 4–40 nodes.
• To design a blockchain that maintains strong security guarantees (including finality and Byzantine fault tolerance) while scaling to hundreds or thousands of geographically distributed nodes.
• To evaluate the performance and robustness of the system under real-world conditions, including network delays, misbehaving nodes, and large-scale workloads.
• To demonstrate that high throughput and low latency can be achieved without sacrificing security or consistency in a partially synchronous, globally-distributed environment.

Proposed method

• The RBBC uses a novel sharding mechanism that assigns distinct groups of proposers and verifiers to different transaction sets, distributing both communication and computation loads.
• Proposals are combined into 'super blocks' from multiple proposers, reducing consensus round-trip overhead and increasing throughput per consensus instance.
• Signature verification is sharded such that each transaction is verified by at least t+1 and at most 2t+1 verifiers, where t is the maximum number of tolerated Byzantine faults.
• The consensus protocol is time-optimal and resilience-optimal, tolerating t < n/3 Byzantine faults in a partially synchronous network, ensuring deterministic finality.
• The system uses ECDSA for transaction signing and the UTXO model for state management, ensuring compatibility with Bitcoin’s security model.
• Experiments were conducted across 14 datacenters on 4 continents using both high-end and low-end machines, with workloads ranging from 1,000 to 50,000 requesters.

Experimental results

Research questions

• RQ1 Can a deterministic, Byzantine fault-tolerant blockchain scale to hundreds or thousands of nodes across geographically distributed datacenters without sacrificing security or finality?
• RQ2 How does sharding proposers and verifiers impact throughput, latency, and load balancing compared to traditional leader-based BFT protocols?
• RQ3 What is the performance of RBBC under real-world network conditions, including variable delays and misbehaving nodes?
• RQ4 How does RBBC’s throughput and latency compare to classic leader-based BFT and randomized BFT protocols like HoneyBadgerBFT in a globally-distributed deployment?
• RQ5 To what extent does the system maintain performance and security under Byzantine attacks, including message tampering and delayed transmissions?

Key findings

• RBBC achieved a peak throughput of 660,000 transactions per second when deployed on 260 machines in a single datacenter with a low fault tolerance parameter t.
• In a global deployment across 14 datacenters with 1,000 replicas, RBBC sustained a throughput of approximately 30,684 transactions per second, with a transaction commit latency of about 3 seconds.
• RBBC’s latency was a third of that of HoneyBadgerBFT, achieving 3-second finality, while also outperforming it in throughput.
• The system scaled to 1,000 nodes across 14 datacenters, demonstrating that sharding proposers and verifiers effectively prevents bottlenecks and avoids the scalability ceiling seen in traditional BFT protocols.
• When under Byzantine attack, RBBC maintained correct consensus decisions and continued to commit transactions, showing resilience to message tampering and delayed transmissions.
• The system became CPU-bound up to 260 nodes, after which performance flattened due to network bottlenecks, indicating that further scaling would require network-level optimizations.