[Paper] Proteus: Append-Only Ledgers for (Mostly) Trusted Execution Environments

Source: arXiv - 2602.05346v1

Overview

Proteus introduces a hybrid consensus design that lets distributed append‑only ledgers keep operating safely even if the Trusted Execution Environments (TEEs) they rely on are compromised. By weaving a Byzantine‑fault‑tolerant (BFT) core inside a classic crash‑fault‑tolerant (CFT) protocol, Proteus retains the low‑latency performance of existing TEE‑accelerated systems while adding a safety net against rare but catastrophic hardware attacks.

Key Contributions

• Hybrid protocol architecture – embeds a BFT consensus layer inside a CFT protocol without adding extra network rounds.
• Message‑free integration – refactors the two underlying protocols so they share the same message flow, preserving the communication cost of standard TEE‑based consensus.
• Formal security argument – proves that integrity is maintained as long as fewer than a third of the nodes are Byzantine or the TEE platform is compromised on fewer than a third of the nodes.
• Prototype implementation – built on top of a popular open‑source BFT library (e.g., HotStuff) and Intel SGX, demonstrating comparable throughput and latency to native TEE‑enabled consensus.
• Empirical evaluation – shows < 5 % overhead in normal operation and graceful degradation when simulated TEE breaches occur.

Methodology

1. Protocol Refactoring

   • The authors start with a standard CFT protocol (e.g., Raft) and a BFT protocol (e.g., PBFT/HotStuff).
   • They align the state‑machine replication steps (leader election, proposal, voting, commit) so that a single round of messages can satisfy both protocols simultaneously.

2. TEE Guarding

   • Critical cryptographic operations (signing, attestation) are performed inside SGX enclaves.
   • Each node runs two logical replicas: a CFT replica that trusts the enclave and a BFT replica that assumes the enclave may be malicious.

3. Safety Switch

   • Nodes continuously monitor enclave health via remote attestation.
   • If an enclave is suspected, the node automatically falls back to the BFT replica’s decisions, which tolerate up to f Byzantine faults.

4. Implementation & Benchmarks

   • The prototype runs on a 5‑node cluster (both LAN and cloud settings).
   • Workloads emulate typical ledger operations: transaction ordering, state updates, and read‑only queries.

5. Security Analysis

   • The paper models two adversarial capabilities: (i) network‑level Byzantine behavior, and (ii) TEE compromise on a subset of nodes.
   • Using a hybrid fault model, they prove that integrity holds unless both the number of compromised TEEs and the number of Byzantine nodes exceed the same threshold (≈ n/3).

Results & Findings

• Performance parity: Proteus adds only a marginal (~5 %) cost compared with the best‑case TEE‑only approach.
• Robustness: When two out of five enclaves are forced to misbehave, the BFT fallback maintains correct ordering and prevents double‑spending.
• Scalability: Experiments up to 9 nodes show linear throughput growth, confirming that the message‑free integration does not become a bottleneck.

Practical Implications

• Higher confidence for blockchain‑as‑a‑service providers that need to meet regulatory audit trails while still leveraging SGX for performance.
• Simplified ops: Developers can keep the same API surface as existing TEE‑enabled ledgers; the hybrid safety logic is transparent to the application layer.
• Reduced risk exposure: Organizations can adopt TEEs without fearing a single zero‑day exploit that would break ledger integrity.
• Potential for cross‑cloud deployments: Since Proteus only requires standard network messages, it works across heterogeneous cloud providers that may offer different TEE implementations (SGX, AMD SEV, ARM TrustZone).

Limitations & Future Work

• Assumes honest majority of TEEs – the security guarantee degrades if more than n/3 enclaves are compromised, which may be unrealistic for highly targeted attacks.
• Prototype limited to Intel SGX; extending to other TEE families could reveal subtle integration challenges.
• Static fault thresholds – the current design does not adapt dynamically if the observed fault rate changes; future work could explore adaptive quorum reconfiguration.
• Formal verification – while a proof sketch is provided, a machine‑checked verification (e.g., using TLA+ or Coq) would strengthen confidence for high‑value deployments.

Proteus offers a pragmatic path forward for developers who want the speed of hardware‑backed consensus without sacrificing the safety nets that pure BFT protocols provide. By marrying the best of both worlds, it paves the way for more resilient, high‑performance distributed ledgers in production environments.

Authors

• Shubham Mishra
• João Gonçalves
• Chawinphat Tankuranand
• Neil Giridharan
• Natacha Crooks
• Heidi Howard
• Chris Jensen

Paper Information

• arXiv ID: 2602.05346v1
• Categories: cs.DC
• Published: February 5, 2026
• PDF: Download PDF