Source-linked AI summary
Breaking Fault Lines: Unifying TEE-Assisted BFT Consensus in Partially Trusted Worlds
Xiaoqing Wen, Tong Liu, Jianyu Niu, Jialin Li, Cong Wang, Yinqian Zhang, Chen Feng
TL;DR
BFT protocols face substantial replication and communication costs, while existing TEE-assisted designs often assume every replica has hardware trust despite practical mixed deployments. The paper analyzes arbitrary partial-TEE deployments and develops dual-quorum and TEE-aware fast-path protocols. It finds that resilience improves only beyond a two-thirds TEE threshold, while Raftel’s evaluation outperforms classical TEE-free BFT and approaches fully TEE-assisted designs.
Problem
Existing TEE-assisted BFT designs commonly assume all replicas have TEEs, although practical deployments mix TEE and non-TEE replicas, leaving consensus under arbitrary heterogeneous trust as an open question.
Source: §1 · p. 2Method
The paper models n replicas with m TEEs and combines TEE-only and mixed quorums with TEE-leader fast paths in HotStuff-style Raftel protocols.
Source: §1 · pp. 2–3, §3.1 · p. 4, §4.2 · p. 5Results
TEE replicas improve fault tolerance only above two-thirds of the deployment, and evaluation shows the protocols outperform classical TEE-free BFT while approaching fully TEE-assisted designs.
Source: §1 · p. 2, §8 · p. 14Takeaways & Limitations
Partial TEE deployment can improve protocol efficiency before it increases fault tolerance, which rises only after TEE replicas exceed a critical fraction of the system.
Source: §8 · p. 14The model assumes each replica’s TEE status remains fixed during a protocol execution.
Source: §3.1 · p. 4
Abstract
from arXiv · showhide
This paper revisits TEE-assisted BFT under a universal partial-TEE model, where an arbitrary subset of replicas execute inside TEEs while the remaining replicas operate without hardware trust guarantees. We show that heterogeneous trust changes the structure of quorum formation and fault tolerance. In particular, we derive a tight resilience bound f < max {n/3, m/2}, where n is the total number of replicas and m is the number of TEE-enabled replicas. The result reveals a sharp threshold phenomenon: TEEs improve fault tolerance only once they exceed two-thirds of the deployment. Guided by this characterization, we introduce two protocol principles: (1) a dual-quorum construction that safely combines TEE-only and mixed quorums, and (2) a TEE-leader fast path that leverages hardware-enforced non-equivocation to reduce both consensus and view-change latency. We realize these ideas in Raftel, which is, to our knowledge, the first HotStuff-style BFT protocol designed explicitly for arbitrary partial-TEE deployments, and in chained-Raftel, a pipelined variant that further accelerates mixed-trust execution. We implement both protocols atop Intel SGX and evaluate them in LAN and WAN environments. Our results show that Raftel achieves up to 625 TPS with sub-670 ms latency in WAN settings, outperforming HotStuff by up to 308 TPS in throughput while approaching the performance of fully TEE-assisted protocols.
1 Introduction
Existing TEE-assisted BFT assumes uniform TEE provisioning, while practical deployments mix trusted and ordinary replicas; this work characterizes that setting and develops protocols for it.
1 Introduction
- TEE-assisted BFT improves fault tolerance only when TEE replicas exceed two-thirds of the deployment; below that threshold, resilience remains bounded by classical TEE-free BFT limits.The paper characterizes this as a sharp threshold rather than a monotonic resilience gain.Source: §1 · p. 2
- A dual-quorum design safely combines TEE-only quorums with mixed quorums, falling back to classical TEE-free quorum formation when enough TEE replicas are unavailable.TEE-enabled replicas cannot equivocate, allowing smaller, faster TEE quorums when sufficient TEE replicas are available.Source: §1 · p. 2
- Raftel uses a shortened commit path for TEE leaders and standard multi-phase BFT for non-TEE leaders, with TEE-certified state accelerating some view changes.Both paths share a quorum and safety framework across leadership changes.Source: §1 · p. 2
- Raftel is presented as the first HotStuff-style BFT protocol designed for arbitrary partial-TEE deployments, with a unified trusted module to reduce enclave transitions.The protocols are implemented atop Intel SGX and evaluated in LAN and WAN settings.Source: §1 · p. 2
- Chained-Raftel pipelines commits so blocks proposed by non-TEE leaders can commit earlier after extension by TEE-led proposals.The optimization targets latency in mixed-trust deployments with only a subset of TEE-enabled leaders.Source: §1 · p. 2
- Up to 1.02× throughput improvement over HotStuff and 61% lower latency accompany Raftel’s 625 TPS and sub-670 ms latency in WAN settings.The paper reports performance approaching fully TEE-assisted protocols.Source: §1 · p. 2
2 Related Work and Motivation
Prior work covers TEE-assisted and hybrid BFT, but the paper identifies a gap in exploiting heterogeneous TEE status; practical deployments motivate a model for partial adoption.
2.1 Related Work
- Prior hybrid-fault systems generally treat replicas uniformly, while MFT studies partial TEE deployment without systematically analyzing how TEE count affects resilience or fully exploiting quorum and fast-commit optimizations.SeeMoRe uses trusted leadership but does not fundamentally change quorum construction.Source: §2.1 · p. 3
2.2 Why a Universal Partial-TEE Model?
- Limited TEE availability, incremental migration, and differing infrastructure constraints make mixed TEE and non-TEE deployments practical, motivating a model that generalizes TEE-free and fully TEE-assisted BFT.TEE support can be restricted by processor generations, cloud instance types, regions, cost, and deployment policies.Source: §2.2 · pp. 3–4
3 System Model and Goals
The model distinguishes TEE and non-TEE replicas and specifies the trust and fault assumptions; the protocol orders transactions in hash-linked blocks subject to safety and liveness goals.
3.1 System Model
- The system has n replicas, m of them TEE-enabled with hardware integrity and non-equivocation guarantees, while non-TEE replicas may behave arbitrarily and TEE status stays fixed during execution.The model includes authenticated communication and assumes TEE keys remain protected; it excludes transient-execution, side-channel, and rollback/forking defenses.Source: §3.1 · p. 4
- Byzantine faults may affect TEE and non-TEE replicas, but corrupted TEE hosts cannot extract keys, forge TEE signatures, or change the attested trusted-component code.The network is partially synchronous, with a message-delay bound after the unknown Global Stabilization Time.Source: §3.1 · p. 4
3.2 System Goals
- Blocks contain client transactions and parent hashes; safety requires honest replicas to commit identical blocks at the same height, and liveness requires eventual inclusion of honest clients’ transactions after GST.Source: §3.2 · p. 4
4 Pushing the Limits: Fault Tolerance Bound and Design Principles
The section derives a tight resilience bound for heterogeneous-trust consensus and uses it to motivate quorum and leader-level designs that exploit TEE non-equivocation.
4.1 Fault-Tolerance Bound
- Consensus tolerates f faults when either n≥3f+1 or m≥2f+1, covering classical mixed-quorum and TEE-dominated regimes.The two conditions are the alternatives in the paper’s tight resilience bound.Source: §4.1 · p. 5
- The necessity argument extends Byzantine agreement’s indistinguishability proof: a corruptible non-TEE set can make two groups observe conflicting executions before GST.The paper states that the full proof appears in Appendix B of the extended version.Source: §4.1 · p. 5
4.2 Principle 1: Dual-Quorum Construction
- The dual-quorum design uses TEE-only quorums when available and mixed quorums otherwise, with valid quorum pairs intersecting at a replica that cannot equivocate.A Mixed-Quorum requires n−f votes from arbitrary replicas; the protocol falls back to it when TEE replicas are slow, unavailable, or insufficient.Source: §4.2 · p. 5
4.3 Principle 2: TEE-Leader Fast Path
- TEE leaders bypass phases whose sole purpose is to defend against leader equivocation; view changes can inherit a TEE-certified proposal, but fall back to the standard rule after non-TEE-led views.The shortened commit path is specific to TEE-enabled leaders, and the view-change shortcut depends on the previous leader being TEE-enabled.Source: §4.3 · pp. 5–6
4.4 Implications
- The designs exploit trust at two levels: heterogeneous quorums and TEE-led fast paths can improve performance even when TEEs are too sparse to improve resilience.The paper identifies chained-Raftel as a pipelined variant of these principles.Source: §4.4 · p. 6
5 Raftel Design
Raftel adapts quorum formation and commit paths to arbitrary mixtures of TEE and non-TEE replicas, using a trusted Checker+ to enforce consistency. Its correctness argument establishes that honest replicas cannot execute conflicting blocks across views.
5.1 Overview
- Raftel is designed for arbitrary TEE/non-TEE mixtures, switching between TEE-only quorums and mixed quorums while using a shortened commit path for TEE leaders.With non-TEE leaders, it falls back to the standard BFT commit path; its partially synchronous pacemaker supports liveness after GST without changing its underlying mechanism.Source: §5.1 · p. 6
5.2 Definitions
- Raftel defines view-and-phase steps, block chains, and signed certificates, with TEE-QCs requiring TEE signers and Mixed-QCs allowing any replica combination.ValidQC checks signer validity and distinctness against the applicable TEE or total-replica quorum threshold.Source: §5.2 · pp. 6–7
5.3 Trusted Components
- Checker+ consolidates proposal checking and prepared-state accumulation, tracks prepared and locked blocks, and enforces consistency across certified protocol steps.It binds certified messages to monotonically increasing protocol identifiers and reduces redundant enclave invocations and context switches.Source: §5.3 · p. 7
5.4 The Algorithm
- TEE leaders use certified proposals to bypass intermediate phases and shorten commits, while non-TEE leaders follow a standard HotStuff-style path with dual-quorum processing.Leaders prioritize TEE-backed certificates when sufficient TEE replicas are available; otherwise, quorums can include arbitrary replicas.Source: §5.4 · pp. 9–10
5.5 Correctness Analysis
- Any two valid TEE-Quorums or Mixed-Quorums intersect in at least one honest or TEE replica, which cannot vote for conflicting blocks in the same view and phase; no two honest replicas execute conflicting blocks.Source: §5.5 · p. 10
- Prepared-block uniqueness and safe extension across views ensure that honest replicas, which execute only after the commit condition is satisfied, cannot execute conflicting blocks.Conflicting blocks cannot both become prepared in one view, and every subsequently prepared block must extend an already prepared block.Source: §5.5 · p. 10
6 Chained-Raftel Design
Chained-Raftel pipelines block justification and commitment across consecutive views, with commit rules adapted to whether a block’s leader is TEE-enabled. Its two-phase workflow overlaps proposals and predecessor finalization while retaining Raftel’s quorum and non-equivocation foundations.
6.1 Overview
- Chained-Raftel pipelines justification and commitment across views: each proposal’s QC certifies its predecessor, allowing adjacent leaders’ work to overlap.The proposal QC certifies the predecessor block while the chain grows, reducing coordination overhead across views.Source: §6.1 · p. 10
6.3 Commit Semantics
- TEE-led blocks commit with a one-chain, while non-TEE-led blocks require a three-chain; a following TEE-led proposal can accelerate commitment of its non-TEE predecessor.If a leader cannot gather sufficient votes, replicas use new-view messages carrying their latest prepared certificates to reconstruct the highest prepared chain.Source: §6.1 · p. 10, §6.3 · p. 11
6.2 Definitions
- Blocks store a parent hash and a QC justifying that parent; the protocol uses dual-quorum certificates and defines one-chain and three-chain structures.A one-chain block directly extends the block referenced by its QC; a three-chain comprises three consecutive parent-linked blocks with consecutive justifications.Source: §6.2 · p. 11
6.4 The Algorithm
- Each view’s leader extends the highest prepared chain, broadcasts a justified proposal, and receives prepare responses; replicas then send prepared certificates to the next leader.Commitment proceeds along the growing chain rather than completing within a single view, using trust-dependent one-chain or three-chain conditions.Source: §6.4 · p. 11
6.5 Correctness Analysis
- The correctness argument preserves quorum-intersection and non-equivocation guarantees while reasoning about dependencies among concurrently pipelined blocks; detailed proofs are deferred to Appendix C.The liveness argument accounts for asynchronous progression across views.Source: §6.5 · p. 11
7 Performance Evaluation
The evaluation compares Raftel and Chained-Raftel with other BFT protocols in LAN, WAN, and a Redis application, and examines performance across fault levels and execution scenarios.
7.2 Scalability Evaluation
- At f=32, Raftel and Chained-Raftel deliver up to 1.02× and 1.05× HotStuff throughput, with latency reductions of 61.46% and 62.84%, respectively.In WAN, Chained-Raftel has 18.9% lower throughput and 21.2% higher latency than Achilles at the same fault threshold.Source: Figure 3 · p. 12, §7.2.1 · pp. 12–13
7.1 System Implementation and Setup
- The prototype uses SGX on cloud VMs; LAN RTT is 0.1 ± 0.02 ms and WAN RTT is emulated at 100 ± 5 ms, with commit metrics used for most protocol comparisons.End-to-end metrics are used for the scalability and client-perceived performance experiments.Source: §7.1 · p. 12
7.2 Scalability Evaluation
- At f=32, Chained-Raftel reaches 67.5 kTPS and 5.95 ms, while Achilles leads at 79.0 kTPS and 5.13 ms.Chained-Raftel has 1.37× and 5.40× the throughput of Damysus and HotStuff, respectively, and reduces their latency by 26.5% and 81.4%.Source: Figure 4 · p. 12, §7.2.2 · p. 13
- Under load increased to saturation, Achilles peaks at 11.5 kTPS, versus 11.1 kTPS for Chained-Raftel and 10.7 kTPS for Raftel.These are end-to-end throughput results at f=8 with 256 B payloads and a batch size of 400.Source: Figure 5 · p. 13, §7.2.3 · p. 13
7.3 Microbenchmark Evaluation
- In LAN, S1 reaches 31.5 kTPS; S2 slightly exceeds S3, while S4 is worst and scenario gaps shrink at smaller system sizes.S1 enables both the TEE-leader fast path and TEE-Quorum; S2 and S3 enable only one of those optimizations.Source: Figure 6 · p. 13, §7.3 · p. 13
7.4 Performance Under Faults
- After a leader crash at 10 seconds, throughput drops near zero at 10.8 seconds, then recovers at 13.3 seconds for a TEE leader or 13.7 seconds for a non-TEE leader.The faster TEE-leader recovery is attributed to Raftel’s TEE-leader fast view change.Source: §7.4 · pp. 13–14, Figure 7 · p. 14
7.5 Overhead Profiling
- Raftel’s SGX overhead is modest: 3.4% to 6.3% throughput reduction and up to 0.2 ms latency increase versus Raftel-C.A critical-path phase involves two enclave interactions for a TEE leader and four for a non-TEE leader.Source: Table 1 · p. 14, §7.5 · p. 14
7.6 KV-Store Application
- In the Redis SET workload, Chained-Raftel reaches 92 TPS and Raftel 84 TPS, below Achilles’ 95 TPS but above HotStuff’s 44 TPS.The workload uses 1 KB values, f=8, and a batch size of 400.Source: Figure 8 · p. 14, §7.6 · p. 14
8 Conclusion
The conclusion frames BFT consensus for deployments where only some replicas have TEEs. It presents a resilience threshold and protocol designs for heterogeneous trust, then reports SGX evaluations of Raftel and Chained-Raftel.
8 Conclusion
- The universal partial-TEE model considers deployments where only a subset of replicas has TEEs and heterogeneous trust changes quorum formation and fault tolerance.Source: §8 · p. 14
- The analysis establishes a tight resilience bound and finds that efficiency improves with partial TEE deployment, while fault tolerance improves only beyond a critical TEE fraction.Source: §8 · p. 14
- Raftel and Chained-Raftel use dual quorums and TEE-aware fast paths; SGX evaluation reports performance above classical TEE-free BFT and approaching fully TEE-assisted designs.Source: §8 · p. 14