Skip to main content
QUICK REVIEW

[论文解读] Proteus: Append-Only Ledgers for (Mostly) Trusted Execution Environments

Shubham Mishra, João Gonçalves|arXiv (Cornell University)|Feb 5, 2026
Distributed systems and fault tolerance被引用 0
一句话总结

Proteus:在具备平台容错的追加仅账本中对基于 TEE 的提交进行审计以在罕见 TEE 受损时保持完整性,同时维持强性能。

ABSTRACT

Distributed ledgers are increasingly relied upon by industry to provide trustworthy accountability, strong integrity protection, and high availability for critical data without centralizing trust. Recently, distributed append-only logs are opting for a layered approach, combining crash-fault-tolerant (CFT) consensus with hardware-based Trusted Execution Environments (TEEs) for greater resiliency. Unfortunately, hardware TEEs can be subject to (rare) attacks, undermining the very guarantees that distributed ledgers are carefully designed to achieve. In response, we present Proteus, a new distributed consensus protocol that cautiously trusts the guarantees of TEEs. Proteus carefully embeds a Byzantine fault-tolerant (BFT) protocol inside of a CFT protocol with no additional messages. This is made possible through careful refactoring of both the CFT and BFT protocols such that their structure aligns. Proteus achieves performance in line with regular TEE-enabled consensus protocols, while guaranteeing integrity in the face of TEE platform compromises.

研究动机与目标

  • 在 TEE 增强的分布式账本中尽管存在罕见的 TEE 受损,也要对强完整性提出需求的动机。
  • 提出一种新的平台容错模型,将跨平台的安全性与可用性分离。
  • 设计 Proteus 将一个 BFT 审计协议嵌入到一个 CFT 账本中且无需额外消息。
  • 确保审计性边界,使受损的 TEE 无法导致不可控的未被检测的背离。
  • 在具有代表性的部署上评估 Proteus,表现出与现有 TEE-账本相当的性能。

提出的方法

  • 引入平台容错(PFT)作为一个将节点与相关的平台故障区分的故障模型。
  • 在具备崩溃容错的账本中嵌入一个拜占庭容错的审计协议,而无需额外消息。
  • 使用哈希链来增量形成法群并将投票与前驱节点绑定。
  • 应用流水线技术,使 BFT 审计与 CFT 提交进度保持同步。
  • 引入视图稳定化,确保在存在已提交但尚未审计的交易时实现安全的视图变更。
  • 提供一个审计 API,确保在 πsafe 平台受损下仍然保证安全性。

实验结果

研究问题

  • RQ1在 TEEs 可能被妥协的情况下,如何在不牺牲性能的前提下实现对追加仅账本的强完整性保障?
  • RQ2能否将 BFT 审计机制嵌入到 CFT 协议中,使审计能够检测并在有界延迟内纠正 TEE 引发的异常行为?
  • RQ3哪种故障模型最能准确描述基于云的 TEE 部署及其对复制和安全性/可用性保障的影响?
  • RQ4需要哪些体系结构原语(哈希链、流水线、视图稳定化)以确保审计吞吐量与提交吞吐量匹配?
  • RQ5在现实应用中,Proteus 的实际部署含义和性能表现如何?

主要发现

  • Proteus 采用平台容错模型实现完整性保障,并在 CFT 协议中嵌入 BFT 审计且无需附加消息。
  • 审计过程从不落后于提交索引超出一个常量界限,从而控制 TEE 受损的扩散半径。
  • Proteus 的审计时延比 Autobahn(一个前沿的 BFT 协议)低 15%。
  • Proteus 的吞吐量损失仅为 11%,并保持与带签名的 Raft 及如微软的 CCF 等生产系统相当的提交性能。
  • 通过五个应用场景的实验,用户可以在提交保证和有条件参与审计之间进行权衡。

更好的研究,从现在开始

从论文设计到论文写作,大幅缩短您的研究时间。

无需绑定信用卡

本解读由 AI 生成,并经人工编辑审核。