Web Proofs与TEE代理：构建可信API交互的技术解析

1. Web Proofs与TEE代理的技术背景解析

在当今API驱动的分布式系统中，确保远程服务交互的可验证性已成为关键挑战。特别是在LLM（大语言模型）代理场景中，代理需要频繁调用外部API工具，而这些交互的真实性直接关系到整个系统的可信度。传统解决方案主要依赖两类技术：TEE（可信执行环境）代理和密码学证明系统，它们各自存在明显的局限性。

TEE代理通过在硬件隔离环境中运行代理代码来确保执行完整性。以Intel SGX和AMD SEV为代表的TEE技术，本质上是在CPU内创建加密内存区域（enclave），即使系统管理员也无法窥探其中运行的程序和数据。这种方案的最大优势是性能开销低（通常仅增加1-20%延迟），但存在两个根本问题：首先，TEE需要完全信任硬件厂商和enclave开发者；其次，代理必须通过TEE节点中转流量，导致所有明文数据都会暴露给TEE操作者。

密码学证明系统（如ZK-SNARKs）则采用数学方法验证计算正确性。虽然理论上完美——验证者只需检查简短证明而无需重现计算，但实际应用中面临巨大性能瓶颈。即使是LeNet-5这样的小型神经网络（6.1万参数），生成每个token的证明也需要约15秒，而现代LLM动辄数十亿参数，使得这种方法在当前技术下完全不实用。

2. Web Proofs的核心机制与创新

Web Proofs提出了一种折中方案：通过改造TLS协议，使半可信的公证人（Notary）能够验证客户端与目标服务器的交互真实性，同时不泄露通信内容。其核心创新在于MPC-TLS（安全多方计算的TLS）协议，该协议将TLS握手过程拆分为需要客户端和公证人共同参与的交互式过程。

具体工作流程分为四个阶段：

1. 连接建立：客户端（Prover）发起与目标服务器的TLS会话，但密钥协商过程改为由客户端和公证人通过MPC协议共同完成。这确保双方必须协作才能完成握手，且公证人只能获得加密流量无法解密。
2. 协同执行：在会话进行中，公证人持续验证交换的加密数据包序列，确保没有篡改或重放攻击。由于采用"诚实但好奇"模型，公证人虽会忠实记录流量，但无法获取明文。
3. 摘要生成：会话结束时，公证人使用其私钥对会话摘要（包括目标服务器域名、数据包哈希等）签名，生成证明π_TLS。该证明具有两个关键属性：只能对应特定服务器的交互，且公证人无法伪造未发生的会话记录。
4. 选择性披露：客户端可向验证者公开π_TLS及部分会话片段（如API响应中的特定字段），而其他敏感信息（如API密钥、完整prompt）保持加密。验证者通过公证人公钥和服务器TLS证书即可确认片段真实性。

关键设计要点：Web Proofs的公证人角色可采用分布式部署（类似阈值签名方案），甚至运行在TEE内，进一步降低对单一实体的信任。但即使公证人被完全攻破，攻击者最多只能拒绝服务，无法伪造历史会话证明。

3. 性能优化与工程实现

原生MPC-TLS协议存在严重的性能问题：建立单个通道的初始延迟高达9.8秒，且通道容量固定导致长会话需要预分配大内存。论文提出了两项关键优化：

动态通道策略：

• 采用短生命周期通道替代单一长连接
• 后台预初始化多个容量递增的通道（M, 2M, 3M...字节）
• 当前通道使用率达80%时自动切换到下一个预备通道
• 通道建立与消息传输并行化

会话压缩技术：

• 对LLM的多轮对话实施增量编码
• 每3-5轮生成对话摘要替代完整历史
• 应用HTTP/2头部压缩算法减少冗余

实测数据显示，优化后32轮对话的总延迟从原生方案的136秒降至42秒（Claude-Haiku模型）。下表对比了不同方案的性能表现：

实现上推荐使用改进版TLSNotary协议，其Go语言实现可达到每秒处理150+个并发会话（c4.standard-4实例）。关键配置参数包括：

type ChannelPolicy struct { InitialCapacity int `json:"initial"` // 建议4KB GrowthFactor float64 `json:"growth"` // 建议1.5 ParallelChannels int `json:"parallel"` // 建议3-5 CompressionLevel int `json:"compression"`// Zstd级别3 }

4. 在LLM代理中的集成方案

将Web Proofs整合到LLM代理架构需要解决三个核心问题：

组件证明系统映射：

1. 对每个API工具𝑡_𝑑，定义注入函数Inject𝑡_𝑑: Σ∗→HTTPReq
2. 实现解析函数Parse𝑡_𝑑: HTTPResp→Σ∗
3. 通过(req_θ, res_θ, π_WP)三元组证明res_θ确实是对应𝑡_𝑑对req_θ的合法响应

验证算法标准化：

def verify(m, proof): # 步骤1：验证公证人签名和服务器证书 if not π_WP.verify(notary_pk, server_cert): return False # 步骤2：检查请求/响应符合AID定义的模板 if not (req_θ.match(aid.template) and res_θ.match(aid.template)): return False # 步骤3：提取并匹配认证值 return m == parse_authenticated(res_θ)

Agent Identity Document（AID）规范：

{ "component_id": "claude-haiku-api", "proof_system": "WebProofs-v1", "notary": { "endpoint": "https://notary.pse.dev", "pubkey": "3059301306..." }, "injection_hash": "sha256:9f86d081...", "parsing_hash": "sha256:5ca3e9b3...", "max_transcript": 65536 }

实际部署时建议采用混合证明策略：对市场数据等公开API使用TEE代理（低开销），对LLM推理等敏感操作使用Web Proofs。VeriTrade案例显示，这种组合方案使认证交易决策的延迟控制在5.8秒±0.7秒，完全满足金融场景需求。

5. 安全边界与限制讨论

虽然Web Proofs显著推进了LLM代理的可验证性，但仍存在几个关键限制：

信任模型缺口：

• 公证人可能通过时序分析推断敏感信息
• 目标服务器与公证人合谋可破坏隐私性
• 解决方案：结合TEE运行公证人代码+差分隐私噪声注入

新鲜度问题：

• 证明不包含时间戳，无法防御重放攻击
• 改进方向：集成Drand随机信标作为时间源

架构约束：

• 当前仅支持线性工具调用链
• 未来需扩展至并行/嵌套代理架构

值得注意的是，Web Proofs本质上解决的是认证（authentication）问题而非自主性（autonomy）。恶意主机仍可通过控制输入流或选择性抑制输出来操纵代理行为。这提示我们需要在协议栈更高层引入抗审查机制，如通过区块链提交执行轨迹的承诺。

6. 典型应用场景与部署建议

Web Proofs特别适合以下三类场景：

金融交易代理：

• 示例：VeriTrade自动交易系统
• 证明内容：价格数据来源、模型推理输入输出
• 部署要点：与CoW Swap等DEX智能合约集成

政策制定工作流：

• 示例：政府法规起草辅助系统
• 证明内容：法律条文检索记录、修订建议生成过程
• 关键配置：公证人采用多机构联合运营模式

医疗决策支持：

• 示例：诊断建议生成代理
• 隐私保护：仅披露ICD编码不暴露完整病历
• 性能调优：采用32KB短通道+每轮摘要

对于希望采用该技术的团队，建议分阶段实施：

1. 先对非关键工具API启用TEE代理
2. 引入1-2个Web Proofs验证的核心组件
3. 建立公证人健康监测（延迟、签名成功率）
4. 逐步将验证逻辑写入智能合约

现有开源生态已提供良好基础：

• TLSNotary-SGX（带TEE增强的公证人实现）
• VetKeeper（轻量级验证客户端）
• AID Generator（交互式身份文档生成器）

随着AI代理日益深入关键决策流程，Web Proofs为代表的可验证执行技术将成为不可或缺的基础设施。其独特价值在于平衡了密码学强度与工程实用性，为构建真正可信的自主系统开辟了新路径。