在十月，“TEE（受信执行环境）”这一术语开始频繁出现在 X 动态中。这让我感到惊讶，因为 TEE 传统上是一个小众话题，主要在系统安全学术界讨论。作为曾在系统安全实验室进行研究的人员，我很高兴看到这一发展。然而，我也好奇为什么 TEE 突然在 Web3 领域获得关注。我还注意到，缺乏能够向大众普及 TEE 概念的内容，这激励我写下这篇文章。

TEE 是一个复杂的概念，没有计算机科学背景的人可能很难完全理解。因此，本文从基本的 TEE 概念入手，解释了为什么 Web3 想要利用 TEE，并讨论了当前 Web3 项目中实现 TEE 的案例以及其局限性。

总之，本文将涵盖以下主题：

• TEE 概念的介绍和现代 TEE 的简要概述
• Web3 生态系统中各种 TEE 实现案例
• TEE 的局限性以及个人对这些局限性的看法
• TEE 在 Web3 生态系统中的未来发展

1. 什么是TEE？

我认为大多数读者可能不具备完全理解 TEE 到底是什么的必要背景知识。由于 TEE 是一个相对复杂的概念，因此我将尽量提供简单的解释。

基本概念

大多数 Web2 服务器通过授权设置来管理数据访问。然而，由于这种方式纯粹是基于软件的，如果获取了更高权限，这种方式基本上就变得无效。例如，如果攻击者获得了服务器操作系统的内核级权限，他们可能会访问服务器上所有权限控制的数据，包括加密密钥。在这种极端情况下，仅通过软件手段几乎无法防止数据被盗。TEE（受信执行环境）试图通过硬件级别的安全性从根本上解决这个问题。TEE 通常被称为“机密计算”，但这其实是一个更广泛的概念，包括确保用户数据隐私的计算机制，如 ZK、MPC 和 FHE。

来源：Jujutsu Kaisen

举个简单的类比，TEE 就像内存中的加密区。TEE 内的数据都是加密的，外部无法直接访问原始数据。即使是操作系统内核也无法读取或修改其原始数据。因此，即使攻击者获得了服务器的管理员权限，他们也无法解密 TEE 内的数据。这个加密区域通常被称为“安全区域”（Enclave）。

创建安全区域并在其中处理数据需要特定的指令集，类似于操作码（opcode）。这些指令使用存储在硬件保护区域中的加密密钥，在安全区域内对数据进行计算。由于 TEE 是硬件级别的安全模块，其实现因 CPU 芯片厂商而异。例如，Intel 支持 SGX，AMD 支持 SEV，ARM 支持 TrustZone。从更广泛的角度来看，这些实现都共享“通过硬件加密保护内存”的概念。

1.1. TEE 如何保护数据

首先，让我们了解最常见的 TEE — Intel SGX、AMD SEV 和 ARM TrustZone 的工作原理，然后介绍一些较新的 TEE 实现。

1.1.1. 经典 TEE

Intel SGX

SGX 在进程级别创建和访问安全区域。下图清楚地展示了启用了 SGX 的程序如何操作。

来源： https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction- Between-pse-and-application-enclaves

在开发过程中，开发人员必须区分受信任代码和不受信任代码。需要由安全区域保护的变量或函数被指定为受信任代码，而其他操作则归类为不受信任代码。当不受信任代码需要将数据输入到受信任代码中，或受信任代码必须与不受信任代码交互时，便使用名为 ECALL 和 OCALL 的特殊系统调用。

来源： https://www.intel.com/content/www/us/en/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

如果用户需要直接与安全区域内的数据进行交互，例如提供输入或接收输出，他们可以通过使用 SSL 等协议建立的安全通道进行通信。

AMD SEV

与在进程级别创建安全区域的 SGX 不同，SEV 在虚拟机级别创建安全区域。分配给虚拟机的内存会被加密，并通过独立的密钥进行管理，保护数据不被服务器操作系统或其他虚拟机访问。虽然虚拟机通常因其沙箱隔离而被认为是安全的，但无法完全排除会破坏这种隔离的漏洞。SEV 旨在在这种情况下提供安全保障。

SEV 在创建虚拟机时通过一个与 CPU 物理隔离的安全处理器生成加密密钥。这些密钥随后用于加密虚拟机内存。下图展示了 SGX 和 SEV 之间的区别。

来源：10.1109/SRDS.2018.00042

SGX 要求开发人员明确将代码划分为不受信任和受信任的部分。相比之下，SEV 对整个虚拟机内存进行加密，因此在实现上相对减少了开发人员的工作量。

ARM TrustZone

与主要为桌面和服务器生产 CPU 的 Intel 和 AMD 不同，ARM 设计的是用于轻量级系统，如移动设备和嵌入式设备的芯片。因此，ARM 的安全区域实现与用于高层架构的 SGX 或 SEV 略有不同。

TrustZone 在硬件级别将系统划分为安全世界（Secure World）和普通世界（Normal World）。使用 TrustZone 的开发人员必须在安全世界中实现安全关键功能，而普通功能则在普通世界中运行。这两个世界之间的过渡通过被称为安全监控调用（Secure Monitor Calls）的特殊系统调用进行，类似于 SGX。

一个主要区别是，TrustZone 的安全区域不仅仅局限于 CPU 或内存，它还包括整个系统，包括系统总线、外设和中断控制器。苹果也在其产品中使用了一个称为 Secure Enclave 的 TEE，功能上与 TrustZone 非常相似。

1.1.2. 高级 TEE

正如我们稍后讨论的，许多原始的 TEE，包括 Intel SGX，由于结构性问题，已遭遇侧信道漏洞和开发挑战。为了应对这些问题，厂商已发布了改进版。随着对安全云计算需求的上升，像 AWS、Azure 和 GCP 这样的平台也开始提供他们自己的 TEE 服务。最近，TEE 概念已扩展到 GPU 领域。一些 Web3 的应用场景现在已经开始实施这些高级 TEE，以下将介绍它们。

云 TEE：AWS Nitro、Azure Confidential Computing、Google Cloud Confidential Computing

随着对云算力服务需求的增加，提供商开始开发自己的 TEE 解决方案。AWS 的 Nitro 是一种与 EC2 实例配合使用的安全计算环境。通过使用专用的 Nitro 安全芯片进行认证和密钥管理，Nitro 实现了计算环境的物理隔离。Nitro 的虚拟机监控程序通过芯片提供的功能保护了安全内存区域，有效防止了用户和云提供商的攻击。

Azure 支持多种 TEE 规范，包括 Intel SGX、AMD SEV-SNP 以及其自有的基于虚拟化的隔离。这种硬件环境选择的灵活性为用户提供了更多选择，但在用户使用多个 TEE 时，可能会增加攻击面。

Google Cloud 提供了利用受信执行环境（TEE）的保密计算服务，重点针对 AI/ML 工作负载。虽然与 AWS Nitro 不同，Google Cloud 与 Azure 一样，利用现有的 TEE 基础设施提供基于虚拟化的隔离。其主要区别在于，Google Cloud 支持像 Intel AMX 这样的 CPU 加速器来处理密集型 AI/ML 任务，并通过 NVIDIA 提供基于 GPU 的保密计算，稍后将详细介绍。

ARM CCA
ARM CCA 于 2021 年底发布，专为云环境量身定制，与 TrustZone 针对单一嵌入式或移动环境设计不同。TrustZone 静态管理预定的安全内存区域，而 CCA 允许动态创建“Realm”（安全区域）。这使得在单个物理设置内可以创建多个隔离的环境。

CCA 可类比为 ARM 版本的 Intel SGX，尽管有显著差异。虽然 SGX 有内存限制，CCA 提供灵活的内存分配。此外，CCA 采用了与 SGX 不同的安全方法，通过加密整个物理内存，而不仅仅是 SGX 中指定的安全区域。

Intel TDX
Intel 推出了 TDX，这是一项在虚拟机层面加密内存的技术，类似于 AMD 的 SEV。此版本解决了关于 SGX(v1) 的反馈问题，包括 256MB 的安全区大小限制以及由于进程级别安全区创建导致的开发复杂性。与 SEV 的主要区别在于，TDX 部分信任操作系统，特别是虚拟机监控程序，用于虚拟机资源管理。此外，虚拟机加密机制也有所不同。

AMD SEV-SNP
SEV-SNP 增强了现有 SEV 模型的安全性。原始 SEV 依赖的信任模型留下了漏洞，允许虚拟机监控程序修改内存映射。SEV-SNP 通过增加硬件管理器来跟踪内存状态，防止这种修改。

此外，SEV-SNP 使用户能够直接进行远程认证，从而减少信任锚点。SEV-SNP 还引入了反向映射表（Reverse Map Table）来监控内存页面的状态和所有权，从而防御恶意虚拟机监控程序攻击模型。

GPU TEE：NVIDIA 保密计算
TEE 的发展传统上集中在 CPU 上，因为其依赖于硬件厂商。然而，处理如安全 AI 训练和训练数据保护等复杂计算的需求突显了 GPU TEE 的必要性。为此，NVIDIA 在 2023 年向 H100 GPU 引入了保密计算功能。

NVIDIA 保密计算提供了独立加密和管理的 GPU 实例，在与 CPU TEE 结合时确保端到端的安全性。目前，它通过与 AMD SEV-SNP 或 Intel TDX 集成来构建保密计算管道。

1.2. 我们如何信任 TEE？

在审视 Web3 项目时，您常常会看到声称通过在 GitHub 上上传代码实现社区治理的说法。但如何验证服务器上部署的程序与 GitHub 上的代码是否一致呢？

区块链提供了一个环境，智能合约因持续的共识机制始终是公开且不可修改的。与此相比，典型的 Web2 服务器允许管理员随时更新程序。为了验证真实性，用户需要比较通过 GitHub 等平台构建的开源程序的二进制文件的哈希值，或者通过开发者签名检查完整性。

同样的原则适用于 TEE 区域内的程序。为了让用户完全信任服务器上部署的程序，他们必须验证（证明）在安全区域内的代码和数据是否保持不变。以 SGX 为例，它使用存储在特殊 庆安全区域中的密钥与 IAS（Intel 验证服务）进行通信。IAS 验证安全区域及其内部数据的完整性，然后将结果返回给用户。总而言之，TEE 需要与硬件厂商提供的验证服务器通信，以确保安全区域的完整性。

2. TEE 在 Web3 中的应用

为什么在 Web3 中使用 TEE？

对于大众来说，TEE 可能显得不太熟悉，因为它的知识通常局限于专业领域。然而，TEE 的出现与 Web3 的原则非常契合。使用 TEE 的基本前提是“信任任何人”。当正确实现时，TEE 可以保护用户数据免受程序部署者、物理服务器所有者，甚至是操作系统内核的干扰。

尽管当前区块链项目在结构上已经实现了显著的去中心化，但许多项目仍依赖于链下服务器环境，如排序节点、链下中继节点和看守机器人。需要处理敏感用户信息的协议，例如 KYC 或生物识别数据，或者那些旨在支持私人交易的协议，面临着信任服务提供商的问题。这些问题可以通过在安全区域内部处理数据来大大缓解。

因此，TEE 在今年下半年受到了广泛关注，特别是在数据隐私和可信 AI 代理等与 AI 相关的主题中。然而，早在此之前，就有尝试将 TEE 集成到 Web3 生态系统中的案例。本文将介绍一些已在 Web3 生态系统中应用 TEE 的项目，涉及的领域不仅限于 AI 部分。

2.1. 保密协处理器

Marlin
Marlin 是一个可验证计算协议，旨在通过 TEE 或 ZK 技术提供安全的计算环境。它们的主要目标之一是开发一个去中心化的 Web。Marlin 管理两个子网络：Oyster 和 Kalypso，其中 Oyster 作为基于 TEE 的协处理协议。

1）Oyster CVM
Oyster CVM（为方便起见称为 Oyster）充当 P2P TEE 市场。用户通过 Oyster 的链下市场购买 AWS Nitro Enclave 计算环境，并在其中部署程序镜像。以下是 Oyster 的抽象结构：

来源： https://docs.marlin.org/oyster/protocol/cvm/workflow/

Oyster 的结构与 Akash 非常相似。在 Oyster 中，区块链的作用是验证每个 TEE 计算环境是否正常运行，这通过名为提供者的观察者来实现。Providers 会实时检查安全区域的可用性，并将其发现报告给 Oyster 网络。它们会质押 $POND 代币，若参与恶意活动，代币可能会被罚没。此外，还有一个去中心化的实体网络，称为“审计员”，负责监督提供者的罚没。每个周期，审计员会被分配任务，并向随机选择的安全区域发送审计请求，这些请求是通过安全区域内部生成的种子来选择的。

然而，Oyster 实现了一个名为 NitroProver 的合约，在链上验证远程证明结果，允许用户在链上验证其购买的 TEE 的完整性。

用户部署的实例可以通过智能合约和 Web2 API 进行访问。计算结果可以通过将其作为预言机的方式整合到合约中。如仪表盘所示，这一功能不仅适用于智能合约，还能去中心化 Web2 服务。

与 Akash 相似，Oyster 也可能面临攻击者接管实例的风险，特别是当链下市场存在漏洞时。在这种情况下，尽管安全区域的数据可能保持安全，但存储在安全区域外的原始数据和服务操作权限可能会受到威胁。对于存储在不可信内存中的敏感数据，开发者必须加密这些数据并单独存储。Marlin 目前提供了一个基于 MPC 的外部存储，使用持久密钥来处理这些情况。

2) Oyster Serverless

Oyster CVM 作为一个 P2P TEE 市场运作，而 Oyster Serverless 则类似于 AWS Lambda（或函数即服务）与 TEE 的结合。使用 Oyster Serverless，用户可以在不租用实例的情况下执行函数，按需付费。

Oyster Serverless 的执行流程如下：

1. 用户创建请求到 Relay 合约；
2. 链下网关服务器通过事件观察用户请求；
3. 网关服务器将用户请求转发到网关协议；
4. 网关协议基于用户请求创建并分配任务给 Serverless 协议；
5. 执行器服务器监听分配给 Serverless 协议的任务，执行任务并提交响应；
6. 响应——即用户请求的结果——依次返回给用户。

通过 Oyster Serverless，用户可以通过智能合约发送 Web2 API 请求或调用智能合约，同时通过 TEE 保证执行的完整性。用户还可以订阅 Serverless 服务进行定期执行，这对预言机抓取器特别有用。

Phala Network

之前在我们的 AI 与加密文章中讨论过，Phala 已经显著转向了 AI 协处理器。

Phala Network 的基本设计包括 Workers 和 Gatekeepers。Workers 作为常规节点，执行客户的计算任务。而 Gatekeepers 管理密钥，使 Workers 能够解密并计算加密的状态值。Workers 处理通过 Intel SGX 加密的合约状态值，读取或写入这些值需要 Gatekeepers 提供的密钥。

来源：https://docs.phala.network/tech-specs/blockchain

Phala 通过支持在 Intel TDX 环境中的机密虚拟机（Confidential VM）SDK 扩展了其产品线。最近，他们与 Flashbot 合作推出了 Dstack。该产品提供了一个远程证明 API，用于验证在机密虚拟机中部署的多个 Docker 容器镜像的操作状态。通过 Dstack 的远程证明，用户可以通过专门的浏览器确保透明性。

另一个重要的进展是他们推出的机密 AI 推理产品，旨在应对近期 AI 项目的激增。Phala Network 现在支持相对较新的 Nvidia 机密计算，旨在通过 ZK/FHE 技术提升 AI 推理服务。此前，这项技术由于高开销而面临挑战，限制了其实际应用。

来源： https://docs.phala.network/overview/phala-network/confidential-ai-inference

下图展示了 Phala Network 机密 AI 推理系统的结构。该系统利用像 Intel TDX 和 AMD SEV 这样的虚拟机级别受信执行环境（TEE）来部署 AI 模型。它通过 Nvidia 机密计算进行 AI 推理，并安全地将结果传回 CPU 安全区域。与常规模型相比，这种方法可能会产生较大的开销，因为它涉及两轮安全区域计算。然而，预计它将比完全依赖 CPU 性能的现有 TEE 基础 AI 推理方法提供显著的性能提升。根据 Phala Network 发布的论文，基于 Llama3 的 LLM 推理开销大约为 6–8%。

其他

在 AI 与加密领域，其他使用 TEE 作为协处理器的例子包括 iExec RLC、PIN AI 和 Super Protocol。iExec RLC 和 PIN AI 分别专注于通过 TEE 保护 AI 模型和训练数据。Super Protocol 正在准备推出一个类似于 Marlin 的 TEE 计算环境交易市场。然而，关于这些项目的详细技术信息尚未公开，我们将在它们产品发布后提供更新。

2.2. 安全智能合约

Oasis（前称 Rose）

Oasis，前身为 Rose，是一个第 1 层（Layer1）区块链，旨在通过在 SGX enclave 中运行执行客户端来保护用户隐私。尽管它是一个相对成熟的链，Oasis 在其执行层创新性地实现了多虚拟机（multi-VM）支持。

执行层称为 Paratime，包括三个组件：Cipher，一个基于 WASM 的机密虚拟机（VM）；Sapphire，一个基于 EVM 的机密虚拟机；以及 Emerald，一个标准的 EVM 兼容虚拟机。Oasis 从根本上保护智能合约及其计算过程，防止节点对其进行任意修改，确保执行客户端始终在 TEE enclave 中运行。下图展示了这一结构。

来源：https://docs.oasis.io/general/oasis-network/

当用户发送交易时，他们通过 Oasis 节点的密钥管理器在安全区域中生成一个临时密钥，并使用该密钥对交易数据进行加密，然后将其传送到计算模块。计算模块从密钥管理器中获取临时密钥的私钥，用于解密安全区域内的数据，执行智能合约并修改节点的状态值。由于交易执行结果也以加密形式交付给用户，因此既操作 Oasis 节点客户端的服务器，也无法观察交易内容。

Oasis 强调其在使用机密 Paratime 创建处理敏感个人信息的 DApp 方面的优势。该功能允许开发需要身份验证的服务，如 SocialFi、信用借贷、CEX 集成服务和基于信誉的服务。这些应用可以在安全的安全区域中安全地接收并验证用户的生物识别或 KYC 信息。

Secret Network
Secret Network 是 Cosmos 生态系统中的第 1 层链，也是最早基于 TEE 的区块链之一。它利用 Intel SGX enclave 对链的状态值进行加密，支持用户的私密交易。

在 Secret Network 中，每个合约都有一个独特的密钥，该密钥存储在每个节点的安全区域中。当用户通过使用公钥加密的交易调用合约时，节点会在 TEE 内解密交易数据并与合约的状态值进行交互。这些修改过的状态值将被记录到区块中，并保持加密状态。

合约本身可以以字节码或源代码形式与外部实体共享。然而，网络通过防止直接观察用户发送的交易数据，并阻止外部观察或篡改当前合约状态值来确保用户交易隐私。

由于所有智能合约的状态值都被加密，因此查看这些值需要解密。Secret Network 通过引入查看密钥（viewing keys）来解决这个问题。这些密钥将特定用户的密码绑定到合约上，仅授权用户可以查看合约的状态值。

Clique，Quex Protocol

与之前介绍的基于 TEE 的第 1 层链不同，Clique 和 Quex Protocol 提供的基础设施使得一般的 DApp 可以将私密计算委托给链下 TEE 环境。这些计算结果可以在智能合约层面使用。它们主要用于可验证的激励分配机制、链下订单簿、预言机和 KYC 数据保护等应用场景。

2.3. 有效性证明系统

一些 ZK L2 链采用多重证明系统来解决零知识证明固有的不稳定性，通常会结合 TEE 证明。现代零知识证明机制尚未成熟到完全信任其安全性，当 ZK 电路出现与健全性相关的漏洞时，需要付出大量努力进行修复。因此，使用 ZK 证明或 ZK-EVM 的链采用 TEE 证明，通过在 安全区域内的本地虚拟机重新执行区块来检测潜在的漏洞。目前，采用包括 TEE 在内的多重证明系统的 L2 链有 Taiko、Scroll 和 Ternoa。我们将简要探讨它们使用多重证明系统的动机及其结构。

Taiko

Taiko 是目前最为突出的（计划成为）基于 Rollup 的链。Rollup 链将排序工作委托给 Ethereum 的区块提议者，而无需维护一个独立的中心化排序器。根据 Taiko 的基于 Rollup 的示意图，L2 搜索者将交易捆绑并批量传递给 L1，L1 的区块提议者随后将这些交易与 L1 交易一同重建，生成 L1 区块并捕获 MEV。

来源：https://docs.taiko.xyz/core-concepts/multi-proofs/

在 Taiko 中，TEE 并不在区块构建阶段使用，而是在证明生成阶段使用，我们将在后文解释。Taiko 由于其去中心化的结构，不需要验证排序器故障。然而，如果 L2 节点客户端代码存在漏洞，一个完全去中心化的设置无法迅速处理这些问题。因此，需要高级别的有效性证明来确保安全性，这使得 Taiko 的挑战设计比其他 Rollup 更加复杂。

Taiko 的区块经历三个阶段的确认：提出（proposed）、证明（proved）和验证（verified）。当区块的有效性由 Taiko 的 L1 合约（rollup 合约）检查时，它被视为提出阶段。经过并行证明者验证后，它进入证明阶段；而当其父区块被证明后，它进入验证阶段。为了验证区块，Taiko 使用三种类型的证明：基于 SGX V2 的 TEE 证明、基于简洁的 RiscZero 的 ZK 证明和依赖中心化多签的 Guardian 证明。

Taiko 采用一种对抗模型进行区块验证，在证明者之间建立了一个安全层级：TEE、ZK、ZK+TEE 和 Guardian。该设置允许挑战者在识别由更高层级模型生成的错误证明时获得更高的奖励。每个区块所需的证明会被随机分配，权重如下：5% 为 SGX+ZKP，20% 为 ZKP，其余使用 SGX。这确保了 ZK 证明者在成功挑战时总能获得更高的奖励。

读者可能会好奇，SGX 证明者如何生成和验证证明。SGX 证明者的主要作用是证明 Taiko 的区块是通过标准计算生成的。这些证明者生成状态值变化的证明，并通过在 TEE 环境中通过本地虚拟机重新执行区块，结合安全区域证明结果来验证环境。

与 ZK 证明生成相比，TEE 基础的证明生成在相似的安全假设下以更低的成本验证计算完整性。验证这些证明涉及简单的检查，例如确保证明中使用的 ECDSA 签名与证明者的签名匹配。

总之，基于 TEE 的有效性证明可以看作是一种验证链完整性的方法，它通过生成安全性稍低的证明，但相较于 ZK 证明，成本大大降低。

Scroll

Scroll 是采用多重证明系统的著名 Rollup，它与 Automata（一个稍后将介绍的证明层）合作，为所有区块生成 ZK 证明和 TEE 证明。这一合作激活了一个争议系统，以解决两种证明之间的冲突。

来源：https://scroll.io/blog/scaling-security

Scroll 计划支持各种硬件环境（目前仅支持 SGX），包括 Intel SGX、AMD SEV 和 AWS Nitro，以最小化硬件依赖性。它们通过使用门限签名从不同环境收集证明，来解决 TEE 中可能出现的安全问题。

Ternoa
Ternoa 优先检测由中心化 L2 实体引发的恶意行为，而不是解决执行本身的漏洞。与 Taiko 或 Scroll 使用 TEE 证明者来补充现有的 ZK 证明不同，Ternoa 在 TEE 环境中使用观察者来检测 L2 排序者和验证者的恶意行为，重点关注无法仅通过交易数据评估的领域。例如，RPC 节点基于 IP 地址审查交易、排序者更改排序算法，或故意未提交批量数据等。

Ternoa 操作一个名为完整性验证链（Integrity Verification Chain，IVC）的独立 L2 网络，用于与 Rollup 实体相关的验证任务。Rollup 框架提供者将最新的排序者镜像提交给 IVC。当一个新的 Rollup 请求部署时，IVC 会返回存储在 TEE 中的服务镜像。部署后，观察者会定期验证已部署的 Rollup 是否按照预期使用排序者镜像。然后，他们提交完整性证明，将验证结果和来自 TEE 环境的证明报告合并，确认链的完整性。

2.3. 以太坊安全性

2.3.1. 区块构建者去中心化

Flashbots BuilderNet
Flashbots 被广泛视为一个 MEV 解决方案提供商，一直在探索受信执行环境（TEE）在区块链技术中的应用。其主要的研究工作包括：

• 探讨在 SGX 安全区域中执行 Geth 及其局限性
• 实现基于 SGX 的区块构建器
• 构建一个基于 REVM 执行的 TEE 协处理器链，运行在 SGX 安全区域中，并配有 Automata 验证层

在本文中，我们将简要概述 Flashbots 当前的角色，并讨论其最近推出的 BuilderNet，这是一个旨在去中心化区块构建的计划。Flashbots 已宣布通过 BuilderNet 完成其现有解决方案的完全迁移。

以太坊采用了一个提议者-构建者分离（Proposer-Builder Separation，PBS）模型。该系统将区块创建分为两个角色：

1. 构建者（Builders）：负责区块的创建和 MEV 提取
2. 提议者（Proposers）：签署并传播构建者创建的区块，以去中心化 MEV 利润

这一结构导致了一些去中心化应用与构建者之间的链下合谋，以获取巨额的 MEV 利润。因此，少数构建者，如 Beaverbuild 和 Titan Builder，垄断了超过 90% 的以太坊区块。在严重的情况下，这些构建者甚至可能对任意交易进行审查。例如，像 Tornado Cash 这样的合规交易被主要构建者积极审查。

BuilderNet 通过增强交易隐私性和降低区块构建者参与的门槛来解决这些问题。其结构大致可以总结如下：

来源：https://buildernet.org/docs/architecture

构建者节点接收用户交易（订单流），由各个节点运营商管理。每个运营商在 Intel TDX 环境中操作开源构建器实例。用户可以自由验证每个运营商的 TEE 环境并发送加密交易。运营商随后共享接收到的订单流，提交区块到 MEV-boost 中继，并在区块提交成功后将区块奖励分发给搜索者和其他参与区块创建的人员。

该结构提供了几个去中心化的好处：

• 可验证性：每个构建器实例都在 TEE 内运行，使用户能够验证构建者是否没有审查交易或任意修改客户端。区块创建贡献者的奖励分配政策也在 TEE 内部透明。
• 抗审查性：在 BuilderNet 中，构建者节点由多个运营商运行，每个运营商有不同的监管政策。这种多样性意味着他们选择排除不同的交易。即使某些运营商审查了交易，其他运营商仍可以选择这些交易。从理论上讲，如果至少有一个不审查交易的构建者，用户的交易仍然可以被纳入区块。BuilderNet 还提供了 L2 审查问题的解决方案，表明通过将区块构建外包给 BuilderNet，L2 可以比单一排序者实现更高的抗审查性。（在这种情况下，审查抵抗的水平可能会受到其他过滤掉交易的组件的影响，例如防火墙）
• 去中心化：当前区块构建者面临依赖中心化基础设施的挑战。BuilderNet 旨在通过整合多个构建者来解决这个问题，首先是 Beaverbuild。随着更多的区块构建者加入 BuilderNet，以太坊的 PBS 结构将实现更高程度的去中心化。目前，只有 Beaverbuild、Flashbots 和 Nethermind 是 BuilderNet 的一部分，其他构建者需要获得许可才能加入，但未来计划将使运营商部署无需许可，并彻底消除中心化基础设施。

2.3.2. 验证者保护

Puffer Finance

Puffer Finance 推出了一个名为 Secure Signer 的工具，旨在减少由于客户端错误或漏洞导致以太坊验证者被罚款的风险。该工具使用基于 SGX 安全区域的签名器，以提供更高的安全性。

来源：https://docs.puffer.fi/technology/secure-signer/

Secure Signer 通过在 SGX enclave 中生成和存储 BLS 验证者密钥，仅在必要时访问这些密钥来运行。其逻辑非常简单：在受信执行环境（TEE）提供的安全保障下，它可以检测验证者的错误或恶意行为。这是通过确保在签署区块或证明之前，插槽严格增加来实现的。Puffer Finance 强调，这种设置使验证者能够达到与硬件钱包相当的安全级别，超越了软件解决方案提供的典型保护。

2.4. L2 排序器去中心化

Unichain
Unichain 是 Uniswap 计划于明年第一季度推出的以太坊 L2 链，在其白皮书中分享了使用受信执行环境（TEE）去中心化 L2 区块构建机制的计划。虽然详细的技术规格尚未发布，但以下是他们关键提案的摘要：

• 排序器-构建者分离：为了增强现有的 Rollup 结构，在该结构中排序和 L2 区块生成由中心化排序者处理，Unichain 与 Flashbots 合作，旨在将 L2 排序者与区块构建者分离。Unichain 的区块构建者将使用开源代码在 Intel TDX 中运行，通过公开发布执行的证明结果来确保透明性。
• Flashblock：Unichain 识别出当前由 Rollup 排序者提供的预确认过程中的可扩展性限制，例如序列化和状态根生成。为了解决这些问题，他们计划引入“Flashblocks”，使用户能够在交易排序后立即通过 TEE 构建者接收待处理的区块。他们强调，在 TEE 中进行排序将确保交易排序仅基于优先费用和提交时间，而不受排序者干扰，从而实现更快的预确认。

此外，Unichain 还打算开发各种基于 TEE 的功能，包括加密内存池、定时交易和受 TEE 保护的智能合约。

2.5. 私有 RPC

Automata
尽管区块链在架构方面已经取得了显著的去中心化成就，但由于依赖于服务器运营商，许多元素仍然缺乏足够的抗审查性。Automata 旨在提供基于 TEE 的解决方案，最小化服务器运营商依赖和区块链架构中的数据暴露。Automata 的重要实现包括开源的 SGX Prover 和 Verifier，TEE Compile（用于验证 TEE 中部署的可执行文件与源代码的匹配），以及通过 TEE 内存池和区块构建器为区块构建机制增加隐私的 TEE Builde。此外，Automata 还允许将 TEE 的远程证明结果发布到链上，这使得它可以公开验证并集成到智能合约中。

Automata 当前运行着 1RPC，这是一个基于 TEE 的 RPC 服务，旨在通过安全区域保护交易提交者的身份信息，如 IP 和设备详情。Automata 强调，由于账户抽象的开发，UserOp 的商业化可能导致 RPC 服务通过 AI 集成推断出特定用户的 UserOp 模式，可能会泄露隐私。1RPC 的结构简单明了，它与用户建立安全连接，将交易（UserOp）传入 TEE，并通过在安全区域中部署的代码进行处理。然而，1RPC 仅保护 UserOp 的元数据，实际的交易方和交易内容在与链上的入口点交互时仍然会暴露。确保交易隐私的更根本方法是通过 TEE 保护内存池和区块构建层。这可以通过与 Automata 的 TEE Builder 集成来实现。

2.6. AI 代理

来源：https://x.com/tee_hee_he

最终将 TEE 元宇宙推向 Web3 的是基于 TEE 的 Twitter AI 代理。许多人可能第一次接触 TEE 是在 10 月底，当时一个名为 @tee_hee_he 的 AI 代理在 X 上亮相，并在以太坊上发行了它的 memecoin。@tee_hee_he 是由 Nous Research 和 Flashbots 的 Teleport 项目联合开发的 AI 代理。它的出现是为了解决当时流行的 AI 代理账户无法证明它们实际上是在转发 AI 模型生成的结果的问题。开发者设计了一个模型，尽量减少了在推特（现为X平台）账户设置、加密钱包创建和 AI 模型结果转发等过程中中心化实体的干预。

来源：@tee_hee_he/setting-your-pet-rock-free-3e7895201f46"">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

他们将 AI 代理部署在 Intel TDX 环境中，通过浏览器模拟生成电子邮件、X 账户密码和 OAuth 代币用于推特（现为X平台）访问，然后移除所有恢复选项。

最近，TEE 在 AI-Pool 中被用于类似的场景，其中 @123skely 成功进行了筹款。目前，AI Meme 代币部署合约并公开地址后，技术上更先进的狙击机器人通常会获得大部分流动性并操控价格。AI-Pool 试图通过让 AI 执行某种类型的预售来解决这一问题。

来源：https://x.com/0xCygaar/status/1871421277832954055

另一个有趣的案例是 DeepWorm，一个具有生物神经网络的 AI 代理，模拟了蠕虫的大脑。与其他 AI 代理类似，DeepWorm 将其蠕虫大脑的安全区域镜像上传至 Marlin Network，以保护其模型并提供可验证性。

来源：https://x.com/deepwormxyz/status/1867190794354078135

由于 @tee_hee_he 开源了部署所需的所有代码，部署可信的、无法“跑路”（rug pull）的、基于 TEE 的 AI 代理变得相当容易。最近，Phala Network 在 TEE 中部署了 a16z 的 Eliza。正如 a16z 在其 2025 年加密市场展望报告中所强调的，基于 TEE 的 AI 代理市场预计将在未来的 AI 代理 Meme 代币市场中发挥至关重要的基础设施作用。

2.7. 社交游戏

Azuki Bobu

Azuki，作为知名的以太坊 NFT 项目，于去年十月与 Flashbots 合作举办了一场独特的社交活动。

来源： https://x.com/Azuki/status/1841906534151864557

该活动通过将 X 账户上传权限委托给 Flashbots 和 Bobu，让他们同时发布推文，类似于一个快闪活动。活动取得了成功，以下是活动成果图。

来源： https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

此活动由 Flashbots 和 Azuki 设计，结构如下：

1. 在 Gramin-SGX 中生成 TLS 私钥和证书，以及以太坊私钥。
2. 用户创建 OAuth 令牌，权限仅限发布一条推文，并通过 TLS 提交到 Flashbots 的 TEE。
3. 在 Arbitrum 上创建了一个合约来管理用户证书，防止双重支付并在用户上传推文后执行事件输出。

Azuki 通过在 Docker Hub 上发布 Enclave 的 Docker 镜像，确保了活动过程的可靠性。它们还将证书透明日志验证脚本和 TEE 环境的远程证明结果上传到 GitHub。尽管 Flashbots 识别出 RPC 和区块链节点的依赖性仍是潜在风险，但这些风险可以通过使用 TEE RPC 或基于 TEE 的 Rollups（如 Unichain）来缓解。

虽然该项目没有实现技术上的突破，但值得注意的是，它仅通过使用 TEE 技术栈就成功地进行了一个值得信赖的社交活动。

3. TEE 的安全性

与典型的软件解决方案相比，TEE 提供了更高的安全性，因为它提供了硬件级的安全保障，软件无法直接破坏。然而，由于一些局限性，TEE 在实际产品中的采用速度较慢，我们将在下面介绍这些局限性。

1) 中心化证明机制
如前所述，用户可以利用远程证明机制来验证TEE保护区域的完整性，并确保保护区内的数据未被篡改。然而，这一验证过程不可避免地依赖于芯片制造商的服务器。不同厂商的信任度有所不同——例如，SGX/TDX 完全依赖于 Intel 的证明服务器，而 SEV 则允许虚拟机所有者直接进行证明。这是 TEE 结构中的固有问题，TEE 研究人员正在通过开发开源 TEE 来解决这一问题，我们稍后会提到。

2) 旁道攻击
TEE绝不应暴露安全区内存储的数据。然而，由于 TEE 只能加密安全区内的数据，因此可能会出现利用附加信息而非原始数据进行攻击的漏洞。自 2015 年 Intel SGX 公开发布以来，许多重要的边信道攻击在顶级系统安全会议上被揭示出来。以下是 TEE 使用场景中潜在的攻击情境，按其影响分类：

• 控制流泄露：恶意操作系统或程序可能通过利用可用信息恢复数据。例如，它们可以利用 CPU 缓存数据访问比 DRAM 数据访问速度更快的事实，从而识别操作代码的执行模式并推断出程序的关键信息，如 RSA 密钥。此外，当恶意操作系统限制内存页访问，导致保护区代码发生页错误时，可能会暴露内存访问模式。通过操控分支目标缓冲区来预测和管理代码分支，也可能暴露代码执行流。此外，攻击者可能通过微观攻击反复执行安全区代码，以推测信息。
• 数据泄露：泄露安全区数据的漏洞可能导致关键攻击，可能会破坏远程证明。值得注意的是，创建模拟安全区代码和数据的影子应用，并对其执行 ROP 攻击（暗 ROP），已导致安全区内的密钥泄露。来自 Intel CPU 的漏洞也可能出现，CPU 会为性能优化而投机执行程序（Foreshadow）。尽管安全区内存受到加密保护，但投机执行的指令访问的数据可能短暂地保留在缓存中。这可以被攻击者利用，通过缓存的旁道攻击来读取安全区数据。
• DoS 攻击：对于 SGX，当内存完整性检查检测到篡改时，系统会停止。这一漏洞已被用于 DoS 攻击，通过故意造成完整性检查失败来触发系统停止。攻击者可以通过反复访问特定的 DRAM 行来诱发相邻行的比特翻转，从而潜在地损坏安全区内存。

尽管 TEE 不是一个能够消除所有攻击向量的系统，并且由于其固有特性，它可能会泄漏不同级别的信息，但这些攻击通常需要强有力的前提条件，例如攻击者和受害者的代码运行在同一 CPU 核心上。这也使得一些人将其称为“带着格洛克的男人”安全模型。

来源：https://x.com/hdevalence/status/1613247598139428864

然而，由于TEE的基本原则是“不要相信任何人”，我认为 TEE 应该能够在这种模型下保护数据，从而充分发挥其作为安全模块的作用。

3) TEE 的实际/近期漏洞
在 TEE 实现中，尤其是 SGX 中，已发现了许多漏洞，大多数漏洞已成功修复。然而，TEE 系统复杂的硬件架构意味着每次硬件发布时都可能出现新的漏洞。除了学术研究，已经有影响 Web3 项目的实际攻击事件，这些事件值得详细审查。

• Secret Network：作为少数遭受真实 TEE 攻击的受害者之一，这个基于 SGX 的项目在 2022 年遭遇了 ÆPIC 泄漏攻击。该攻击瞄准了最近 Intel CPU 中的 AVX（高级向量扩展）指令集，利用 AVX 操作中的投机执行模式恢复存储在安全区中的加密密钥。Secret Network 使用共识种子来解密私密交易。攻击者成功提取了这一种子，从而解密了网络上所有历史私密交易。该漏洞的更多细节可以在 sgx.fail 网站上找到。
• SGX 根密钥泄露：今年 8 月，安全研究员 Mark Ermolov 宣布成功解密了 SGX 的根配置密钥和根封装密钥，这些密钥是 SGX 加密信任模型的关键组件。这些密钥通常由物理 Fuse 控制器设备中的复杂逻辑保护。然而，发现了一个关键漏洞，这些密钥的副本在操作过程中仍然保留在内部缓冲区中。尽管仅拥有这两把密钥并不能完全破坏SGX，但获得全球包装密钥可能会使整个 SGX 系统暴露于漏洞之下。尽管 SGX 在 2021 年后 Intel 商业 CPU 中已被淘汰，但由于仍有多个项目在使用它，它仍然是一个潜在的攻击向量。
• AMD SEV-SNP 漏洞：AMD SEV 是一种相对较新的 TEE 实现，具有虚拟机级别的广泛保护范围，与 SGX 相比，历史上显示出较少的漏洞。然而，IEEE S&P 2025 会议接受了一篇讨论“BadRAM”的论文，揭示了一个针对 AMD SEV-SNP 的漏洞，这表明即使是现代 TEE 实现也并非免疫于安全缺陷。BadRAM 利用 DDR4 和 DDR5 内存模块在物理内存中创建地址空间别名。攻击者通过使用一款价格约为 10 美元的 Raspberry Pi Pico，可以修改内存芯片，欺骗 CPU 关于物理内存大小的信息。这有效绕过了 AMD SEV-SNP 的 RMP（反向映射表）保护机制。该漏洞的更多细节可以在 badram.eu 网站上找到。

这些案例表明，“完全安全的 TEE”是无法实现的，用户应当意识到新硬件发布时可能存在的漏洞。

4. 结论：开源是未来

在11月，Paradigm 的 Georgios Konstantopoulos 概述了一个关于机密硬件演进的框架，将安全硬件分为五个不同的级别：

• 级别 1：为预言机和跨链应用提供足够的机密性，安全性依赖于供应链。示例包括 SGX。
• 级别2：保留级别 1 的安全性，同时增强开发者体验，并支持像 OAuth 账户委托等高级应用，如 Teleport。Gramine SGX 是这一层级的典型代表。
• 级别 3：在级别 1 的安全性基础上扩展 GPU 支持，支持更复杂的应用，如私密和可验证的机器学习。Intel TDX + Nvidia Confidential Computing 代表了这一层级。
• 级别 4：使用开源指令集和公开可验证的制造过程，去除对硬件供应商的依赖，如 OpenTEE 所示。
• 级别 5：实现理想状态，多个 OpenTEE 通过 FHE/MPC 协同工作，即使个别硬件单元被攻破，也能保持完整性。

目前，像 Phala Network 的机密 AI 推理这样的项目运行在级别 3，而大多数服务仍处于级别 2，使用云 TEE 或 Intel TDX。尽管基于 Web3 的 TEE 项目最终应该过渡到级别 4 硬件，但当前的性能限制使得这一目标暂时不可行。然而，随着像 Paradigm 等主要风险投资公司以及 Flashbots 和 Nethermind 等研究团队致力于 TEE 的民主化，再加上 TEE 与 Web3 原则的契合，它有望成为 Web3 项目的关键基础设施。

关于 ChainLight

Ecosystem Explorer 是 ChainLight 的报告，提供了从安全角度对 Web3 生态系统中流行项目的内部分析，由我们的研究分析师编写。我们的使命是帮助安全研究人员和开发者共同学习、成长，并致力于使 Web3 变得更安全。我们会定期发布免费的报告。

要获取由获奖专家撰写的最新研究和报告： 👉 关注 @ChainLight_io @c4lvin

ChainLight 成立于 2016 年，拥有获奖的专家团队，提供量身定制的安全解决方案，强化您的智能合约，助力您在区块链上蓬勃发展。

免责声明：

1. 本文转载自【Chainlight】。所有版权归原作者所有【c4lvin】。若对本次转载有异议，请联系Gate Learn 团队，他们会及时处理。
2. 免责声明：本文表达的观点和意见仅代表作者个人观点，不构成投资建议。
3. Gate Learn 团队将该文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。