[Paper] T-RBFT: A Scalable and Efficient Byzantine Consensus Based on Trusted Execution Environment for Consortium Blockchain

Source: arXiv - 2604.16053v1

Overview

The paper introduces T‑RBFT, a two‑layer consensus protocol designed for permissioned (consortium) blockchains. By leveraging Trusted Execution Environments (TEEs) and a sharding‑style grouping of nodes, T‑RBFT dramatically cuts down the message traffic and latency that traditional Byzantine Fault‑Tolerant (BFT) protocols incur, while still keeping strong safety guarantees.

Key Contributions

• Hybrid two‑layer design – combines a TEE‑assisted BFT protocol for cross‑shard agreement with a lightweight Raft‑style protocol inside each shard.
• Dynamic sharding based on runtime metrics – nodes are grouped on‑the‑fly according to CPU, network latency, and load, ensuring balanced partitions and better resource utilization.
• TEE‑enabled fault detection – enclaves provide attested execution and tamper‑proof logs, allowing the protocol to assume a small, bounded number of faulty replicas typical in consortium settings.
• Formal safety & liveness proofs – the authors extend classic BFT proofs to the two‑layer architecture, showing that the system tolerates up to f Byzantine nodes per shard while preserving global consistency.
• Empirical evaluation – experiments on a 100‑node testbed demonstrate up to 3× higher throughput and 40 % lower latency compared with state‑of‑the‑art two‑layer protocols (e.g., PolyBFT, HotStuff‑Sharding).

Methodology

1. Node Grouping (Sharding)

   • Each validator periodically reports its current CPU usage, network RTT, and pending transaction queue length.
   • A lightweight coordinator (running inside a TEE) runs a greedy bin‑packing algorithm to assign nodes to k shards, aiming for homogeneous load and minimizing inter‑shard communication.

2. Intra‑Shard Consensus

   • Within a shard, validators run an enhanced Raft protocol.
   • Raft’s leader election is accelerated by TEE‑generated randomness, reducing split‑brain scenarios.
   • Log replication follows the usual majority rule (⌈n/2⌉+1), which is sufficient because the consortium already limits the proportion of Byzantine nodes.

3. Inter‑Shard (Global) Consensus

   • The shard leaders act as representatives in a TEE‑assisted BFT round (similar to PBFT).
   • All messages exchanged among leaders are signed and sealed inside the enclave, guaranteeing integrity even if a leader’s host OS is compromised.
   • The protocol only needs 3f+1 total leaders to tolerate f Byzantine leaders, a far smaller quorum than a full‑network BFT.

4. Safety & Liveness Guarantees

   • The authors prove that any block committed by a majority of shards is globally consistent, leveraging the deterministic ordering of Raft inside shards and the total order enforced by the global BFT round.

5. Evaluation Setup

   • Simulated a consortium blockchain with 10‑100 validators across 2‑5 shards.
   • Benchmarked against baseline PBFT, HotStuff‑Sharding, and a pure Raft‑only design.
   • Measured throughput (transactions per second), end‑to‑end latency, and network traffic (bytes exchanged per consensus round).

Results & Findings

• Communication savings stem from the fact that only k leaders (instead of all n nodes) participate in the expensive BFT round.
• Latency reduction is largely due to the fast Raft leader election inside shards and the TEE‑provided deterministic randomness, which eliminates many view‑change retries.
• Scalability: Adding more shards linearly increases throughput while keeping latency roughly constant, confirming the sharding intuition.

Practical Implications

• Enterprise blockchains (e.g., supply‑chain, finance, inter‑bank settlement) can adopt T‑RBFT to achieve near‑datacenter transaction speeds without sacrificing Byzantine safety.
• Developer ergonomics – the protocol exposes a familiar Raft API for intra‑shard operations, making integration into existing blockchain frameworks (Hyperledger Fabric, Quorum) straightforward.
• Reduced operational costs – fewer cross‑node messages translate to lower bandwidth usage and less CPU load on validator hardware, which is attractive for cloud‑hosted consortium networks.
• Security posture – leveraging TEEs (Intel SGX, AMD SEV) adds hardware‑rooted attestation, simplifying compliance audits and enabling regulators to verify that only authorized nodes participate.

Limitations & Future Work

• TEE dependency – the security guarantees hinge on the availability and correct configuration of enclaves; hardware bugs (e.g., SGX side‑channel attacks) could undermine trust.
• Shard rebalancing overhead – dynamic regrouping incurs a brief pause while leaders are re‑elected; the paper notes this could become a bottleneck under highly volatile workloads.
• Assumption of limited Byzantine fraction – the design assumes a small number of faulty nodes per shard, which may not hold in adversarial consortium settings where insider threats are possible.
• Future directions suggested by the authors include: (1) integrating proactive secret‑sharing to mitigate TEE compromise, (2) exploring adaptive shard sizing based on workload prediction, and (3) extending the model to heterogeneous environments where some validators lack TEEs.

Authors

• Wen Gao
• Xinhong Hei
• Yichuan Wang

Paper Information

• arXiv ID: 2604.16053v1
• Categories: cs.DC
• Published: April 17, 2026
• PDF: Download PDF