作者：Weikeng Chen

原文链接：https://blog.polyhedra.network/tee-in-polyhedra/

Polyhedra 正在为其跨链桥接协议、预言机系统以及可验证 AI 市场引入新一层安全机制，依托 Google Confidential Computing 技术实现可信执行环境（Trusted Execution Environment，简称 TEE）。在广泛调研当前主流 TEE 解决方案后，Polyhedra 选择基于 Google Confidential Space 搭建 TEE 安全模块，并率先验证了其零知识-TEE 结合（ZK-TEE）的全新证明机制 —— 实现在 Google Cloud 上运行的计算结果可被 EVM 链端验证，开辟了可信计算与区块链原生互操作的新路径。

该安全层将逐步部署至 Polyhedra 旗下多款基于零知识的核心产品，涵盖多个链之间的跨链互操作系统。同时，Polyhedra 还计划通过预编译合约形式，将 TEE 证明能力与 TEE 安全防护的 AI 应用原生集成至其自主研发的 EXPchain 中。

什么是 TEE？

TEE，全称是“受信执行环境”（Trusted Execution Environment），是一种 CPU 技术。它可以让 CPU 在加密且保护完整性的内存中执行运算 —— 就连云服务提供商（比如 Google Cloud）、操作系统，甚至是在同一个虚拟机环境中的其他系统，都无法查看这些数据。

换句话说，TEE 能在硬件层面保证数据在使用过程中的机密性和安全性。

这种技术其实已经被广泛使用了。例如苹果的设备默认启用了全盘加密功能（也叫“数据保护”），它就是基于苹果芯片上的 TEE 实现的。只有当用户用指纹或密码解锁设备后，才能访问设备里保存的密码和密钥等敏感信息。微软的 Windows 系统也一样，近几个版本都支持 TEE 加持下的全盘加密（BitLocker）。这样只有在操作系统和启动流程没有被篡改的前提下，磁盘才会解锁。

Polyhedra 的 TEE 技术愿景：构筑安全可信的下一代互联网基础设施

从去年开始，Polyhedra 就一直在专注于跨链互操作和 AI 的安全性、可信性与可验证性三大核心维度。我们正在推进多个产品研发，其中部分已正式发布。总体而言，Polyhedra 的核心聚焦点涵盖三个关键方向：

跨链桥接协议
ZKML 与可验证 AI 智能体
可验证 AI 市场，包括 MCP 服务器（多方协同推理）

安全性始终是 Polyhedra 的首要目标，也是创始团队组建 Polyhedra Network 的初衷。我们已通过 deVirgo 实现对底层共识机制的可验证性，包括以太坊的完整共识验证。

同时，Polyhedra zkBridge 已支持的诸多链大多采用 BFT 风格的 PoS 共识，这些系统的验证难度相对更低。然而，在保障系统安全性的同时，我们也意识到引入可信执行环境（TEE）对于改善用户体验至关重要。TEE 能够实现更低成本、更快终局确认时间、更强的非链上互操作性以及更高的数据隐私保护，为我们的产品体系提供重要补充。TEE，将成为我们安全架构中关键的一环，也是跨链与 AI 未来发展的加速器。

更低成本：Polyhedra 在 ZK 系统中的降本策略

Polyhedra 一直致力于通过多种技术路径降低跨链桥接成本。这一成本主要来源于目的链上对零知识证明的生成与验证开销，不同区块链的验证成本差异较大，以太坊的验证费用通常偏高。在现网运行中，Polyhedra 主要通过“批量处理”机制来优化成本。在 zkBridge 中，核心步骤“区块同步”并非对每个区块都执行，而是每隔数个区块统一进行，该区块间隔会根据链上活跃度动态调整，从而有效降低整体成本。

不过，在一些冷清时段（例如某条链的凌晨），用户可能是“唯一一个发起跨链操作的人”。为了不让这类用户等待太久，zkBridge 会直接触发同步、生成证明并完成验证，这样就会产生额外的成本。这些成本有时由用户自己承担，也可能分摊到其他用户的交易费用中。对于大额跨链交易，为了确保安全，证明成本几乎不可避免。但对于小额交易，我们正在探索一种新机制：由 Polyhedra 预支资金流动性，在可控范围内承担部分风险，为用户带来更快、更便宜的跨链体验。

除了跨链桥，Polyhedra 也在持续优化 zkML 的生成与验证成本。其旗舰产品 Expander 库已广泛被其他团队用于 ZK 机器学习场景，并在向量化、并行计算和 GPU 加速等方面取得显著进展。此外，其证明系统也进行了多轮优化，大幅降低了证明生成开销。在链上验证方面，Polyhedra 正在其自主公链 EXPchain 中部署用于 zkML 验证的预编译模块，该功能预计将在下一阶段测试网中上线，从而实现 zkML 证明的高效验证，并计划推广至更多区块链生态。

尽管 Polyhedra 已实现对参数规模高达 80 亿的 Llama 模型的证明，但当前的生成过程尚未做到“即时”。对于更大规模的模型，尤其是图像或视频生成类模型，证明生成时间仍然较长。Polyhedra 聚焦于构建 AI 智能体系统，在乐观执行架构下运行模型——用户如遭遇恶意操作，可通过 zkML 证明向链上发起申诉并惩罚操作者，无需每次都生成证明，仅在挑战时使用。证明成本相对可接受，但智能体操作者需锁定一定资本作为保险金，产生资金占用压力。

因此，对于运行超大模型、对安全性要求更高或期望更低费用的用户，引入另一层安全机制（如 TEE）将非常关键。TEE 不仅可用于保障链上 AI 应用（如交易机器人）的可信性，也可在技术上提升系统抗攻击能力，从而降低所需保险资金的规模。

快速终局：应对 Rollup 上链延迟挑战

Polyhedra 亦在持续推进“快速终局”（Fast Finality）的能力，尤其是为了解决部分 Rollup 在以太坊 L1 上结算周期过长的问题。由于依赖以太坊 L1 的状态共识以继承其安全性，因此终局延迟会影响用户体验与交互效率。这一问题在乐观 Rollup（如 Optimism 和 Arbitrum）中尤为明显，其提款期通常长达 7 天，显然难以满足大多数用户的实时性需求。而在 zkRollup 中，尽管安全性更强，但许多项目仍采取每 30 分钟至 10-12 小时不等的延迟批量提交方案，也造成一定延迟。

为了解决跨链互操作性的问题，Polyhedra 在与 Arbitrum 和 Optimism 的集成中采用了结合零知识证明（ZK proofs）的状态委员会（State Committee）机制。相同的技术也已部署于 opBNB 上。该方案通过多个节点运行这些 Rollup 的全节点客户端，主要任务是从官方 RPC API 获取最新区块数据。在可能的情况下，我们引入了 RPC 多样性以增强系统的安全性和可用性。每台机器会对桥接合约中即将跨链传送的事件进行签名，并最终将多个签名聚合为一个可在链上验证的 ZK 证明。之所以采用签名聚合设计，是为了支持更多的验证节点参与，提升去中心化程度。

该状态委员会系统已稳定运行约一年时间。然而，需要注意的是，状态委员会所生成的 ZK 聚合签名在安全性方面，尚不及针对整个共识过程生成的完整 ZK 证明。因此，我们在快速确认机制中对该方案进行了限制：仅适用于小额资产的跨链转移；对于大额资产，Polyhedra 推荐用户使用官方的 L2 到 L1 桥接渠道，以获得更强的安全保证。

在 ZKML 场景中，尤其是需要即时执行的场景（如 AI 交易机器人），实现“快速终局”显得尤为关键。为此，Polyhedra 正在探索在其可验证 AI 技术栈中引入 TEE（可信执行环境）作为解决方案，使 AI 推理过程运行在具备 TEE 的计算环境中，保障数据的可信性和执行结果的可验证性。

我们计划利用 Google Vertex AI 的模型库，证明某一模型的输出确实源自 Vertex AI 的 API 调用，或通过 TEE 证明结果来自官方的 ChatGPT 或 DeepSeek API 服务。虽然这需要一定程度上信任平台方（如 Google、OpenAI），但我们认为这是一个可以接受的工程假设，尤其是在与纯链上计算的 ZKML 搭配使用时。

若用户希望运行自定义模型，我们亦可在支持 TEE 的 Nvidia GPU 实例（Google 近期已支持）中部署该模型。这一机制可与 ZKML 证明并行使用：ZK 证明可在系统遭到质疑时生成，或延迟生成作为保险补充机制。例如，在面向 AI 交易机器人或代理的保险机制中，运营方可在保额达到上限前生成 ZKML 证明，用于释放安全保证金，从而提升代理系统的交易吞吐量，使其在原有保额下处理更多任务。

非区块链互操作性：连接链上与真实世界的可信通道

Polyhedra 一直在探索将零知识证明（ZKP）应用于非区块链场景，代表性案例包括中心化交易所（CEX）的储备证明系统，通过对数据库进行隐私保护验证，从而实现可审计性。此外，我们也积极推进链与链外系统之间的互操作，例如为 AI 交易机器人和现实资产（RWA）提供股票、黄金、白银等传统金融资产价格的可信预言机，或通过 Google 登录、Auth 0 登录等社交方式实现链上身份认证。

链外数据主要分为两类：

JWT（JSON Web Token）签名数据：可直接在 EVM 上验证（尽管 gas 成本较高），或经 ZK 证明包裹后进行验证。Polyhedra 采用的就是后者方式。
TLS（传输层安全协议）数据：可通过 ZK-TLS 进行证明，但当前技术要求用户信任用于重建 TLS 密钥的 MPC 节点。ZK-TLS 在处理简单网页或 API 数据时性能良好，但处理复杂网页或 PDF 文档时成本较高。

在这一背景下，Polyhedra 引入了 ZK-TEE 方案。我们可以在可信执行环境（TEE）中运行一个 TLS 客户端，通过 Google Confidential Computing 生成可信计算证明，再转化为 ZK-TEE 证明上链，实现链外数据的安全读取与验证。

该 TLS 客户端为通用架构，运行高效，可支持几乎所有 TLS 连接场景，包括但不限于：

访问 Nasdaq 等金融网站获取股票价格
代表用户操作股票账户进行买卖交易
通过在线银行进行法币转账，实现与传统银行账户的“跨域桥接”
搜索与预订航班和酒店
从多个中心化交易所（CEX）和去中心化交易所（DEX）实时获取加密货币价格

在 AI 场景中，非区块链数据的可信性尤为重要。当下的大型语言模型（LLM）不仅接收用户输入，还会使用搜索引擎或 LangGraph、Model Context Protocol（MCP）等方式动态获取外部数据。通过 TEE，我们可以验证这些数据源的真实性。例如，AI 代理在解决数学问题时可调用 Wolfram Mathematica 或远程的 Wolfram Alpha API 服务，并使用 TEE 保障这些调用过程与结果的完整性。

隐私保障：构建可信的 AI 推理环境

当前，zkBridge 主要利用 ZK 证明提升安全性，并未与隐私链集成。但随着 AI 应用的兴起（如链上 AI 代理和交易机器人），隐私成为新一轮核心需求。我们正在深入探索多个关键应用场景：

在零知识机器学习（ZKML）领域，核心应用之一是验证私有模型的正确推理。这类模型通常将参数保密（用户无需知晓具体参数），有时连模型架构等商业机密也会隐藏。私有模型非常普遍：OpenAI 的ChatGPT、Anthropic 的Claude以及谷歌的Gemini均属此类。当前最先进的模型大多保持闭源有其必然性——需要通过商业收益覆盖高昂的训练研发成本，这一现状预计还将持续数年。

尽管私有化有其合理性，但在自动化环境中，当模型输出直接触发链上操作（如代币买卖）尤其是涉及大额资金时，用户往往需要更强的可追溯性和可验证性保障。

ZKML 通过证明模型在基准测试和实际推理中保持一致性来解决这一问题。这对 AI 交易机器人尤为重要：用户基于历史回测数据选择模型后，既可确保模型持续采用相同参数运行，又无需知晓具体参数细节，从而完美平衡了验证需求与隐私保护。

我们同时探索可信执行环境（TEE）技术，因其能提供 ZK 无法实现的用户输入隐私保护。ZKML 要求证明方掌握包括模型参数和用户输入在内的全部信息。虽然理论上可以结合零知识和多方计算（MPC），但对大模型而言，这种组合会导致验证速度急剧下降——不仅模型推理，整个证明过程都需在 MPC 内完成。此外，MPC 本身也存在节点共谋风险。而 TEE 能有效解决这些问题。

在多方计算服务器（MCP）隐私保护方面，TEE 同样发挥关键作用。Polyhedra 正在开发的可验证 MCP 市场将列明通过 ZKP 或 TEE 实现可验证性、可追溯性和安全性的 MCP 服务器。当模型在配备 TEE 的 Proof Cloud 中运行，且仅调用标有隐私认证的 MCP 服务时，我们能确保用户输入数据始终加密于 TEE 环境，永不外泄。

TEE 是如何工作的？

前文我们已探讨了 Polyhedra 的技术愿景，以及可信执行环境（TEE）如何与零知识证明（ZKP）共同构成我们产品体系中的关键支柱。接下来，我们将进一步深入介绍 TEE 的工作原理。

TEE 通过创建安全飞地(enclave)实现计算与数据的全封闭保护，但这仅是基础能力。其革命性价值在于通过远程认证(remote attestation)机制实现公开可验证性。

远程认证的工作流程包含三个关键环节：

飞地初始化阶段：CPU 对安全飞地内的可执行程序二进制代码进行完整性度量
证明生成阶段：通过AMD 密钥分发服务(KDS)或英特尔认证服务(IAS)生成可公开验证的证明
证书链验证阶段：该证明包含签名及证书链，其根证书分别由 AMD 或英特尔签发

当证明文件能通过根证书验证时，即可确认两点核心事实：

计算确实在配备 TEE 技术的 AMD/英特尔芯片飞地中执行
签名内容包含的程序信息与模型输出等关键数据真实可信

Polyhedra 的创新突破在于：通过 ZK-TEE 证明技术，将 TEE 认证证明压缩为可在链上高效验证的精简证明。以 zkBridge 为例，我们即将展示该技术如何为多款产品提供安全保障。

SGX、SEV 与 TDX：TEE 技术的选择与比较

在构建可信执行环境（TEE）支持的产品体系过程中，Polyhedra 深入研究了当前主流的三种 TEE 技术实现，分别为：

Intel SGX（Software Guard Extensions）：适用于部分 Intel 服务器级 CPU；
AMD SEV（Secure Encrypted Virtualization）：广泛适用于 AMD EPYC 系列 CPU；
Intel TDX（Trust Domain Extensions）：面向新一代 Intel Xeon 处理器的技术。

以下是我们对这三种技术的比较分析，以及对实际选型的思考：

SGX：最早落地的 TEE 技术

Intel SGX 是目前可用时间最长的可信执行环境（TEE）方案之一。然而在主流云服务提供商中，仅 Microsoft Azure 支持 SGX，而 Google Cloud 和 AWS 均已转向支持 SEV 与 TDX 等替代方案。

SGX 的核心机制是在 Intel 处理器内部划定一块隔离内存区域（Enclave），CPU 直接对该内存区域进行管理和访问控制。通过 REPORT 指令，CPU 对 enclave 中的执行代码进行测量，从而生成可信证明，确保其中运行的二进制代码在创建时即处于确定性、可重现的状态。

这一模型具有显著的低层级特性：

开发者必须确保 enclave 内的程序和数据在创建时处于一致性状态；
并确保其作为可信计算根（Root of Trust），不依赖任何未验证的外部输入或动态加载代码。

这一底层设计让 SGX 对开发者而言始终不够友好，几乎持续了整个过去十年。早期的 SGX 开发几乎只能使用 C/C++ 编写 enclave 程序，不仅无法支持多线程等常见操作系统特性，而且往往需要对原有应用程序乃至其依赖库进行大幅改动。

为了简化这一开发过程，近年来开发者尝试将 SGX 应用部署在虚拟化操作系统（如 Gramine）上运行。Gramine 提供了类操作系统的封装，帮助开发者在不完全重写代码的前提下适配 SGX 环境。然而，使用 Gramine 仍需格外谨慎：如果依赖的某些 Linux 常用库未被充分支持，依然可能造成程序异常。尤其在追求性能优化时，仍需对底层实现做出不少调整。

值得注意的是，业界已经出现了更易落地的替代方案：AMD SEV 和 Intel TDX，它们在保障安全可信的前提下，避免了 SGX 所面临的大量开发门槛，为构建隐私计算基础设施提供了更高的灵活性和实用性。

SEV 与 TDX：面向虚拟化的可信计算解决方案

与 SGX 仅保护一小块称为 enclave 的内存区域不同，AMD SEV 和 Intel TDX 旨在保护运行于不可信主机上的整台虚拟机（VM）。这种设计思路的背后逻辑，源自现代云计算基础设施的架构特性。例如，Google Cloud 等云服务商通常在物理服务器上运行 hypervisor（裸金属管理程序），用于在同一台机器上调度来自多个用户的虚拟计算节点。

这些 hypervisor 广泛使用硬件级虚拟化技术，如 Intel VT-x 或 AMD-V，以替代性能较差的软件虚拟化方法，后者已逐渐被淘汰。

换言之，在云计算环境中，CPU 本身已天然具备对虚拟机与 hypervisor 的识别能力与隔离控制。CPU 不仅提供跨虚拟机的数据隔离机制，确保资源公平分配，还对网络与磁盘访问进行虚拟化隔离。实际上，hypervisor 越来越多地被简化为软件前端接口，而真正承担虚拟机资源管理任务的，是底层的硬件 CPU。

因此，在云端虚拟机之上部署受保护的执行环境（enclave）变得自然而高效，这正是 SEV 与 TDX 的核心设计目标。

具体来说，这两项技术通过以下机制，确保虚拟机在不可信环境中仍具备可信计算能力：

内存加密与完整性保护：SEV 和 TDX 在硬件层对虚拟机内存进行加密，并附加完整性校验机制。即使底层 hypervisor 被恶意篡改，其也无法访问或修改虚拟机内部的数据内容。
远程证明（Remote Attestation）机制：它们通过集成可信平台模块（TPM）为虚拟机提供远程证明功能。TPM 会在启动时度量虚拟机的初始状态，并生成带有签名的证明，确保虚拟机在一个可验证的、可信的环境中运行。

尽管 SEV 与 TDX 提供了强大的虚拟机级别保护机制，但在实际部署中仍存在一个关键挑战，也是许多项目常见的陷阱：TPM 默认只度量虚拟机操作系统的启动序列，而不会涉及其上运行的具体应用程序。

要确保远程证明涵盖运行在虚拟机内的应用程序逻辑，通常有两种方式：

方法一：将应用程序写入操作系统镜像（hardcode into the OS）

此方法要求虚拟机启动至一个经过加固、仅可执行目标应用的操作系统，从根本上排除运行任何非预期程序的可能性。推荐的实践是采用微软提出的 dm-verity 机制：在启动时，系统仅挂载一个只读磁盘映像，该映像的哈希是公开且固定的，确保所有可执行文件都经过验证，且不能被篡改或替换。验证过程可通过 AMD KDS 或 Intel IAS 完成。

这种方式的复杂之处在于：应用程序必须重构为只读磁盘结构的一部分。如果需要临时可写存储，则需使用内存文件系统或加密/具完整性校验的外部存储。同时，整个系统需以 Unified Kernel Image (UKI) 格式封装，包括应用、操作系统映像与内核。尽管实现成本较高，但它可以提供高度确定性的可信执行环境。

方法二：使用 Google Confidential Space（推荐）

Google Confidential Space 提供了一种托管式解决方案，它实质上也是对方法一的抽象与封装。其核心思想与前者一致：确保整个虚拟机环境的可信性，但开发者只需构建标准的 Docker 容器镜像即可，无需手动配置内核与磁盘映像。Google 会负责底层的加固 OS 镜像与远程证明配置，极大地简化了开发流程。

我们将在未来的博客中进一步分享基于 Confidential Space 的技术方案实现，包括密钥管理与部署策略等细节。

TEE 在 Polyhedra 产品体系中的应用总结

1.桥接协议（Bridges）

在桥接协议的实现中，Polyhedra 将在现有的零知识证明（ZK）或状态委员会的基础上，加入额外的安全检查。这些检查可能包括运行轻客户端（如果可用），或通过多条规范化的 RPC API 服务与相应的链进行交互，确保数据传输的安全性和可靠性。

2.零知识机器学习（ZKML）

在 ZKML 领域，Polyhedra 可能会运行一个 TEE 代理，调用 Google Vertex API 或外部 AI API 服务进行推理，并验证模型输出是否来自 Vertex API，且没有被篡改；或者在没有使用 Google 模型库的情况下，直接通过 Nvidia GPU 上的保密计算运行 AI 模型。需要注意的是，在此方案中，隐私保护是其附带的副产品。我们可以轻松隐藏模型的参数、输入和输出，从而保障数据的私密性。

3.可验证 AI 市场（Verifiable AI Marketplace）

对于可验证 AI 市场，包括 MCP 服务器，Polyhedra 采用类似的策略：通过运行 TEE 代理，或在可能的情况下直接运行应用程序。例如，在需要数学求解的 MCP 服务中，我们可以选择搭建 TEE 代理连接到 Wolfram Alpha，或者直接运行 Mathematica 的本地副本。在某些场景下，我们必须使用 TEE 代理，例如与机票预订系统、Slack 或搜索引擎交互时。需要特别指出的是，TEE 还可以将一个不符合 MCP 标准的服务（例如任意 Web2 API）转化为符合 MCP 的服务，方法是通过代理在服务之间进行架构和格式的转换。

展望：TEE 加入将加速产品落地并带来多重价值

TEE 技术的引入是 Polyhedra 技术栈的重要补充，未来我们将率先在跨链桥模块中落地部署，并逐步推广至 AI 推理和去中心化服务市场中。TEE 技术将大幅降低用户成本、加速交易最终确认、实现更多生态系统的互操作性，并为用户提供全新的隐私保护特性。

SEND launches Blinks browser onlyblinks