注意差距：TEE远程证明的不足与为何需要云证明

TEE 证明本身并不能提供安全使用它们所需的所有信息。通过物理访问或控制特权软件发起的攻击也应得到缓解。我们设计了数据中心执行保证（DCEA）远程证明协议，将远程证明的范围扩展到可信的数据中心硬件。我们通过结合两个信任根来实现这一点——一个来自芯片制造商，另一个来自数据中心运营商。英特尔还宣布了平台所有权认可（POE），专门用于应对物理攻击。这些协议在减少 TEE 的攻击面和信任依赖方面迈出了一大步。

并不像“把它放进 TEE”那么简单

在可信执行环境（TEE）（如英特尔信任域扩展（TDX））中运行的机密虚拟机（CVM）已在 Web3 领域获得了广泛采用。Flashbots 在云端 TDX 实例上运行多项服务（BuilderNet、Flashbox……）。随着 AI 采用的浪潮，TEE 的采用也急剧增加，模型现在可以在 TEE 内运行，以提供关于与你喜爱的 LLM 共享的敏感信息的保证。

TEE 的采用正在激增——但针对它们的已发布攻击数量也在激增。 这让我们有理由格外警惕。为了负责任地应对这一局面，了解哪些攻击与当今 TEE 的部署方式实际相关，以及哪些类型的攻击可以排除或已有防御措施，将有所帮助。

对攻击进行分类的一种方法是根据攻击者对目标机器的访问类型：物理访问或远程访问。拥有物理访问权限的攻击者可以密切监控和控制与 TEE 交互的硬件，旨在提取支撑其完整性保证的远程证明密钥。成功的攻击者随后将能够在 TEE 外部伪造远程证明，并将透明环境伪装成 CVM。关键是，这些攻击不需要高带宽的数据窃取——即使泄露少量秘密位也足以破坏整个安全模型。

TEE 远程证明报告认证了 CPU 型号、微码修订版和测量的启动状态，但不提供处理器物理位置的任何证据。 因此，对一个服务器拥有物理控制权的恶意操作者可以生成完全有效的远程证明，同时让服务器在一个不受控制的地下室中运行，而不是在一个提供物理安全性的可靠数据中心。最近的攻击已经使这一点具体化：研究人员已经演示了通过 DDR5 内存上的物理总线插接（TEE.fail、WireTap）提取 SGX 远程证明密钥，这些技术也会影响 TDX。无论机器是放在超大规模数据中心还是车库里，远程证明看起来都是一样的。

虽然这些物理访问攻击令人印象深刻且成本低廉，但 TEE 供应商认为它们不在考虑范围内，他们将具有物理访问权限的攻击者排除在其威胁模型之外。自从英特尔 SGX v1 从消费级 CPU 系列中退役转而支持多插槽、服务器级版本，从而允许创建包含更多内存并随后基于虚拟机（VM）镜像的飞地以来，现代 TEE 已公开被标榜为仅限云的技术。

在向云端迁移的过程中，远程证明（RA）基本保持不变。RA 让验证者确认什么代码正在运行：固件版本、客户内核、VM 镜像。它们将这一信息的真实性根植于 CPU 供应商担保的硬件中。远程证明不能告诉你的是那段代码在哪里运行。 这并不是一个假设性的担忧，因为插接攻击已经证明了这一点。

我们称之为物理访问差距：商业 TEE 明确将具有物理访问权限的对手排除在其威胁模型之外，但它们产生的远程证明并未提供任何证据表明 CVM 在物理访问确实受到控制的设施内的硬件上执行。除了插接攻击之外，这一差距还使得能够达到同样结果的代理或中继攻击成为可能。代理攻击产生跨多台机器组合的有效远程证明工件——一台在云端，一台在攻击者的物理控制之下——以虚假地声称在受保护的基础设施上进行可信执行。

注意：接下来的三节将深入探讨这些差距如何在 Web3 部署中显现，以及数据中心执行保证（DCEA）和平台所有权认可（POE）如何解决这些差距的。如果你主要对实际意义感兴趣，可以直接跳到“总结：一个必要的快照，而非最终目标”。

为什么 Web2 从不关心（而 Web3 必须关心）

为了理解为什么物理访问差距在某些上下文中比其他上下文中更重要，引入 TEE 部署中涉及的几个不同角色会有所帮助。在本文中，我们提及三个参与者：

• CVM 操作者 ⓞ 部署和维护在机密虚拟机（CVM）内运行的工作负载镜像。
• 主机管理员 ⓜ 运行底层主机操作系统、虚拟机监控程序以及（在适用的情况下）虚拟 TPM。在托管的云环境中，这是云提供商。
• 硬件提供商 ⓟ 拥有物理服务器和容纳它的数据中心设施。

在 Web2 中，物理访问差距几乎无关紧要。在超大规模云提供商（例如 GCP）部署的公司与 Google 签订合同，信任其运营安全，并且在出现问题时有法律追索权。角色 ⓞ、ⓜ 和 ⓟ 通常合并为同一个实体，或合并为由商业协议约束的各方。主机到 CVM 的接口不是对抗性的：同一组织部署并控制双方，你通过合同和基于 IP 的验证来信任机器提供商。

一些提供商已经通过专有服务公开了部分平台来源信息。微软的 Azure Attestation（MAA）验证 TEE 证据并颁发远程证明Token。在 GCP 上，vTPM 认可密钥证书由 Google 的从属 CA 签名，并编码了 VM 的实例 ID 和项目。这些为验证者提供了特定提供商生态系统内的一些位置信号。

但这些方法是特定于供应商的，不能跨云推广——验证者必须理解每个提供商的专有格式并信任其特定的 CA 层级结构。依赖多个云提供商对于硬件提供商的去中心化至关重要。更重要的是，这些解决方案对裸机部署都不起作用，而裸机部署是延迟敏感的 DeFi 工作负载的硬性要求，因为托管云 VM 无法满足性能需求。对于 Web3 参与者——他们通常是伪匿名的，并且可能缺乏与基础设施提供商的任何合同关系——没有带外渠道来验证来源信息。

也就是说，对云证明的需求并不限于 Web3。任何多方场景中，如果不同组织必须在 TEE 内共享敏感数据——例如，医疗机构合作开发专有 AI 模型，该模型使用患者数据进行训练，并且必须在特定司法管辖区运行——当 CVM 操作者、主机管理员和硬件提供商是独立的实体时，也会面临类似的信任差距。Web3 只是让这成为常态而非例外。

角色分离问题

Web3 打破了 Web2 的信任模型，因为参与者是互不信任的、伪匿名的，并且常常处于直接的经济竞争中。多个独立的各方，其利益不一致，必须围绕共享基础设施进行协调，而不信任任何单一操作者。

这并非抽象概念。考虑一下 Flashbox 沙箱，Flashbots 使区块构建者能够与原子套利搜索者机器人协作，以获取区块底部（BoB）回刷。该设置涉及三个不同的方：TDX 操作者（Flashbots）部署并维护 CVM 镜像，区块构建者将敏感的状态差异流传入 CVM，搜索者将专有的套利代码上传到 TEE。每一方的利益直接冲突：搜索者的代码必须对操作者和构建者保持私密，而构建者的订单流必须对搜索者保持私密。TEE 远程证明为这种相互隐私提供了机制，但只有当搜索者能够相信经过远程证明的机器确实位于受控制的数据中心，而不是位于操作者物理控制的硬件上时，这才成立。

更广泛地说，在整个 MEV 供应链中，TEE 保护服务的用户隐式地与上面定义的三个角色（ⓞ、ⓜ 和 ⓟ）交互，并且没有一个角色信任其他角色：

• 操作者 ⓞ 可能与运行底层操作系统和虚拟机监控程序的主机管理员 ⓜ 不同。而 ⓜ 可能在由并非完全可控的硬件提供商 ⓟ 拥有的基础设施上运行。每个边界都是一个潜在的攻击面。
• 搜索者不信任操作者。一个在延迟上竞争的 CEX-DEX 搜索者担心信息窥探。一个原子长尾搜索者，其年收入取决于一个高度专业化的策略来每年获取少量区块，将任何泄露视为生存威胁。
• 订单流提供者也不信任操作者。他们传输用户交易——有时用于主要的 L2 平台——并需要防止抢先交易和选择性泄露的保证。
• 用户可能是搜索者、区块构建者、私人订单流提供者，或者一般来说，是依赖 TEE 提供的远程证明能力的人。

因为这些角色由不同的实体履行，主机到 CVM 的接口变成了一个关键的攻击面。虚拟机监控程序、vTPM、客户机与主机之间的通信渠道：所有这些都由工作负载所有者没有理由信任的一方控制。（值得注意的是，某些主机到 CVM 的攻击向量——例如受控信道攻击——可以通过加固 CVM 工作负载本身来部分缓解，例如通过 oblivious 内存访问模式。然而，这是特定于工作负载的，并不通用。）

标准的 TEE 远程证明告诉搜索者，它正在上传代码的 CVM 在 TEE 中按预期运行。它没有告诉他们，它是否运行在操作者可能发动物理侧信道攻击的基础设施上。这就是“云证明”所要填补的差距。

云证明：将隐式变为显式

云端每一次 TEE 部署都隐式地信任数据中心操作者不会发动物理攻击。这一点隐式地融入了英特尔 TDX 和 AMD SEV-SNP 的威胁模型中。云证明将这种隐式假设变得显式且可验证。

更准确地说，我们将云证明定义为一种密码学证明，它表明机密工作负载在已知基础设施环境内的硬件上运行，将客户机远程证明与提供商的信任根绑定，以便远程验证者能够确认在可信的数据中心硬件上执行。该威胁模型假设主机软件栈（操作系统、虚拟机监控程序、vTPM）是对抗性的，但 CPU/TPM 硬件根及其供应链在远程证明证据方面是受信任的，而更广泛的供应链保证仍然不在考虑范围内。云提供商在物理完整性和正确的证书颁发方面是受信任的，但在任何软件可见状态的机密性方面则不受信任。

这并非要消除对云提供商的信任。而是要将已经存在的信任关系正式化，并为验证者提供一种验证它的方法。作为推论，当你为了安全而信任一个参与者时，知道谁是那个参与者就非常重要。云提供商成为远程证明链中一个被命名的、负责任的参与者，而不是一个隐形的假设。我们无法避免让他们参与进来。只要 TEE 无法可信地防御物理对手，让一个可识别的数据中心所有者表明其机队中某台机器的所有权将成为威胁模型的一部分。我们只是让事情变得更清晰。

因此，云证明最好作为一个概念而不是一个单一协议来讨论。它可以通过我们开发的数据中心执行保证（DCEA）协议、英特尔最近的平台所有权认可（POE），或更简单的机制（例如云提供商签名的 PPID 列表）来实例化。正如我们将在接下来的章节中展示的那样，每种方式在部署简便性和所提供的保证强度之间都提供了不同的权衡。

DCEA

我们在 2025 年的立场论文中首次提出了云证明的问题，随后开发了 DCEA 协议。DCEA 通过建立两个并行的信任根并将它们绑定在一起，来弥合物理访问差距：一个来自 TEE 制造商（例如英特尔的 TDX 远程证明链），一个来自基础设施所有者（通过离散 TPM（dTPM）或虚拟 TPM（vTPM））。

在深入探讨其工作原理之前，先介绍几个关键概念：

• 平台配置寄存器 (PCR) 是 TPM 内部的专用寄存器，用于记录启动过程中加载的每个软件组件的累积哈希值。它们构成了平台状态的防篡改日志。
• 运行时扩展测量寄存器 (RTMR) 在英特尔 TDX 内部具有类似用途，记录 TD 启动配置和运行时状态的测量值。
• 远程证明密钥 (AK)： TPM 驻留的签名密钥，用于签署引用（远程证明报告）。其来源与平台认可密钥 (EK) 绑定，EK 由 TPM 制造商提供。

DCEA 的核心是利用 vTPM 的 PCR 和 CVM 的 RTMR 之间存在重叠测量的事实。虽然 vTPM 的 PCR 捕获静态远程证明——反映平台的启动时状态——但 CVM 的 RTMR 提供动态远程证明，测量可信执行飞地内的运行时环境。验证者可以交叉引用这两个独立 root 的工件；静态和动态测量链之间的任何不一致都表明 TEE 远程证明和平台引用来自不同的机器。

我们关注两种部署场景——托管 CVM 和裸机——每种场景都有一组不同的要求和可能的威胁。裸机系统尤其容易受到代理攻击，攻击者在其自己的硬件上运行 TD，同时将 TPM 交互中继到合法的云服务器。

DCEA 的工作原理

DCEA 定义了两种部署场景和一个适用于两者的四步协议。

• 场景 I——托管 CVM： 云提供商管理主机操作系统、虚拟机监控程序和 vTPM。此处，提供商被信任会颁发正确的证书并维护测量启动——但提供商可见的 vTPM 状态不会损害 TD 工作负载的机密性，因为 TEE 仍然提供其标准的隔离保证（假设 paravisor 是开源且可验证的）。vTPM 的 PCR 值和 TD 引用的 RTMR 在共同的测量集上重叠，从而实现交叉验证。
• 场景 II——裸机： 租户在具有离散 TPM (dTPM) 的单租户服务器上运行 TD。整个主机软件栈（操作系统、虚拟机监控程序、vTPM）都是不可信的。我们依赖于动态信任根测量 (DRTM)，如英特尔可信执行技术 (TXT) 所实现的那样。DRTM 将固件、内核和 vTPM 二进制文件测量到平台 dTPM 的 PCR 17–18 中。此场景提供了更强的保证——特别是因为固件和内核本身也被测量到信任链中——但代价是更高的复杂性。

四步协议：

1. 建立测量启动和平台根。 平台使用英特尔 TXT 启动，它会重置 TPM 并将早期启动组件（ACM、SEAM 加载器）的测量值扩展到 PCR 17。然后将主机操作系统和 vTPM 二进制文件测量到 PCR 18，从而创建主机栈的硬件支持摘要。
2. 配置并密封 AK。 TPM 生成一个远程证明密钥 (AK) 并将其私钥密封到绑定到 PCR 17–18 的策略中。这确保只有当主机的启动状态与批准的测量配置匹配时，AK 才能签署引用。AK 的来源通过提供商颁发的证书或 EK 锚定的注册器与平台认可密钥 (EK) 绑定。
3. 客户机内证据绑定。 TD 将 (v)TPM 公共 AK 的哈希值嵌入其远程证明报告中（通过 report_data 或 MRCONFIGID）。这创建了一个传递绑定：TD 的证据链接到密封的 AK，而密封的 AK 又链接到 TXT 测量的平台。只有由经过远程证明的 AK 在正确的测量状态下签署的引用才会被接受。
4. 验证者工作流。 验证者发出基于随机数的挑战，并获得 TD 报告（由英特尔引用飞地签署）和 (v)TPM 引用（由密封的 AK 签署）。然后验证：TD 报告包含预期的 hash(AK_pub)；两个工件中的随机数都是新鲜的；TD RTMR 与引用的 PCR 一致；EK 链和 QE 签名确认了硬件来源。

DCEA 的实际应用

再次考虑代理攻击，攻击者在其自己的硬件上运行 TD，同时将 TPM 交互中继到合法的云服务器。DCEA 通过其绑定机制的组合来挫败这种攻击。TD 嵌入的 AK 哈希揭示了任何跨机器的引用，因为攻击者的本地 TD 引用了与远程平台上密封的 AK 不同的 AK。AK 密封到 PCR 17–18 完全阻止了密钥在平台外的使用。随机数新鲜度阻止了简单的重放，而带有时间限制的并发挑战使得长代理路径变得可观测。

DCEA 目前已在 Google Cloud 上使用英特尔 TDX 和 vTPM 进行了原型实现。在撰写本文时，GCP 是为数不多的同时提供托管 CVM 和具有硬件 TPM 访问权限的裸机 TDX 的主要云平台之一，尽管其他提供商（例如 OpenMetal）正在探索类似的配置。该设计本身可推广到任何提供可比远程证明原语和重叠测量寄存器的 TEE；AMD SEV-SNP 目前缺乏原生的 RTMR 风格字段，尽管可以通过将测量哈希嵌入客户镜像的命令行（类似于今天传递 dm-verity 根哈希的方式）来近似等效逻辑。Arm 的机密计算架构 (CCA) 提供了良好的适配性，具有四个 Realm 可扩展测量值 REM[0–3]——提供了 DCEA 所利用的相关远程证明功能。然而，目前市场上还没有可用的芯片。

与 POE 不同，DCEA 是一个重量级的协议，它提供了更丰富的保证集——包括主机软件完整性验证——但需要与平台的启动链和 TPM 基础设施进行更深入的集成。这种集成依赖性也是 DCEA 今天主要的实际限制：云提供商必须公开 TPM 访问并支持测量启动（例如英特尔 TXT），而并非所有提供商目前都提供这些功能。提供商可能不愿公开这些原语，因为这样做会增加操作复杂性，并可能暴露他们希望保持不透明的内部平台细节。

英特尔 POE

正如我们讨论过的，云证明是当今远程证明栈中缺失的一个特性。我们将云证明定义为一种密码学证明，它表明机密工作负载在已知基础设施环境内的硬件上运行，将客户机远程证明与提供商的信任根绑定，以便远程验证者能够确认在可信的数据中心硬件上执行。DCEA 是云证明的一种可能实例化。最近，英特尔发布了一份技术报告，描述了他们自己的方法，称为平台所有权认可 (POE)。POE 的工作方式与 DCEA 不同。它更轻量，提供的保证集也更窄，同时仍然满足核心的云证明要求。

回顾一下中继攻击：恶意行为者将远程证明签署请求从地下室的服务器中继到合法的云 TPM。这是对依赖 TEE 的去中心化网络的生存威胁，并将成为我们评估 POE 适用性的基准。

英特尔 POE 是一种将平台远程证明与已验证的物理所有权绑定的机制。它目前被设计为现有远程证明栈的一个侧车，并有明确的路径直接集成到英特尔 SGX/TDX DCAP 远程证明引用中——这将使 POE 认可与现有的测量值（MRTD、RTMRs）一起绑定到同一签名工件中。我们的描述完全基于英特尔的技术报告，并且我们目前还不知道具体的部署时间线。值得注意的是，该设计不涉及英特尔特定的功能，理论上可以被其他 TEE 制造商采用。

因此，POE 有望成为云位置验证的事实标准。然而，虽然它解决了直接的硬件身份问题，但它应对了物理攻击，却没有提供关于主机到 CVM 软件接口的保证。

POE 的工作原理

POE 操控了两个关键标识符：

1. PRID（处理器注册 ID）： 一个永久性的、不可变的 ID，对硅片来说是唯一的。
2. PIID（平台实例身份）： 一个可重置的 ID，在平台首次启动时生成。

在这种模型中，云提供商充当受信任的权威机构。在供应链阶段，提供商将其机队的 PRID 收集到一个受信任的供应链清单中。然后，他们签署一个 POE“Token”（通常采用 IETF CoRIM 格式），证明具有特定 PIID 的机器属于他们。关键是，PIID 和 PRID 通过英特尔签名的平台组成清单 (PCM) 绑定在一起，该清单以密码学方式证明给定的 PIID 属于由特定、已入库的处理器组成的平台。这确保了即使在导致 PIID 重新生成的事件之后，只有当下层硅片之前已注册到受信任的库存中时，才能颁发有效的 POE。

当 CVM 生成远程证明引用时，硬件会自动嵌入 PIID。然后，验证者将其与提供商签名的 POE 进行交叉引用。如果引用中的 PIID 与有效 POE 中的 PIID 匹配，你就获得了密码学证据，证明该工作负载正在运行于之前被该云提供商认可为其数据中心之一的硬件之上。

POE 的实际应用

如果攻击者试图在他们自己未经认可的硬件（“傀儡机器”）上运行 CVM，他们将无法生成有效的引用，因为他们的机器的 PIID 没有来自受信任云提供商的相应签名。

此外，POE 依赖于操作纪律。如果一台机器退役或出售，提供商会执行“出厂重置”，这会重新生成 PIID——或者，启动撤销请求（类似于英特尔为受损硬件撤销特定 PCK 证书的方式）——从而有效地使旧的认可失效。这使得攻击者更难使用旧的、废弃的数据中心硬件来伪装成有效的云节点，前提是数据中心保持其机队清单的更新。

局限性：缺少主机状态的标识

POE 提供了强大的硬件身份保证。然而，虚拟机监控程序和主机软件栈默认位于 TEE 可信计算基 (TCB) 之外——这对 TDX 和 SEV-SNP 普遍成立，并非 POE 特有的限制。POE 并未改变这个边界。主机到 CVM 的接口仍然是一个难以完全推理的广泛攻击面，研究人员已经展示了实际的微架构攻击，这些攻击在云 TEE 威胁模型内利用虚拟机监控程序——主要针对 AMD SEV-SNP，同时也指出了 TDX 页表和缓存的类似担忧（尽管英特尔已对 TDX 模块应用了缓解措施，以限制虚拟机监控程序引发的 VM 退出并为侧信道信号增加噪声）。

POE 文档明确指出 PIID“在……可信计算基 (TCB) 恢复期间保持不变”。这是有意设计的：它允许云提供商在无需重新颁发所有权证书的情况下修补固件。然而，这意味着 POE 并未将远程证明扩展到主机软件栈的测量启动。

POE 证明了谁拥有机器，但没有证明什么软件启动了它。在 Web3 上下文中，这种区别很重要：我们信任云提供商不会发动物理攻击（这正是云证明的全部意义所在），但我们可能不信任他们——或者一个被入侵的内部人员——不会运行一个利用主机到 CVM 接口的修改过的虚拟机监控程序。这些是不同层级的信任。一个恶意或受损的主机操作者理论上可以在有效的、经认可的硬件上运行一个修改过的虚拟机监控程序，以发起侧信道攻击。DCEA 通过英特尔 TXT 测量主机栈的方法正好解决了这个特定层面。

总结：一个必要的快照，而非最终目标

POE 是一个巨大的进步。它将“云证明”从一个理论概念转变为一个可部署的特性，有效地对抗了低成本的代理攻击。对于绝大多数用户来说，知道硬件位于安全的 Azure 或 GCP 设施中就足够了。

DCEA 更进一步，通过将远程证明也绑定到主机软件栈（包括虚拟机监控程序）的测量状态，解决了一类 POE 有设计上未涵盖的主机到 CVM 攻击，但代价是便携性较差且需要更深的平台集成要求。

单独来看，这两种方法都不能满足所有用例。POE 为你提供了硬件属于已知提供商的证明。DCEA 包含了硬件与工作负载之间软件层完整性的证据，但部署起来更具挑战性。它们代表了使“云证明”成为可部署现实的当前技术水平。

然而，我们也必须认识到，云证明协议本质上是一个供应链快照。它们信任提供商的数据库和维护流程。一个恶意的数据中心操作者可能与外部对手勾结，将经认可的机器转移出去而不重置它们，从而使对手在物理上将该机器运行在数据中心之外的同时获得 POE 认可。（当然，如果激励足够高，恶意的提供商也可能直接发起物理攻击——提醒我们许多物理攻击仍不在 TEE 威胁模型的考虑范围内。）如果一台有效的机器被物理窃取并在未进行出厂重置的情况下重新启动，它将保留其 PIID。在 POE Token过期、提供商主动更新其清单或触发撤销之前，那台被窃取的机器仍然可以生成有效的“云”远程证明。人们会期望超大规模云提供商运行自动化的清单监控和撤销流程，但安全保证最终取决于操作纪律。

信任供应链问题

当你追溯整个基础设施供应链时，问题变得更加深入。云计算并非单一服务。它是一个由提供商组成的复杂分层栈，每个提供商具有不同的责任和信任属性。

像 Google 这样的超大规模云提供商并非简单地“运营一个数据中心”。硬件可能由一个实体制造，在另一个实体运营的设施中组装，通过由另一个团队维护的软件进行管理，并通过分销商或托管服务层提供给客户。这个链条中的每个环节都是一个潜在的信任边界，可能具有利用任何信息不对称的强大动机。

对于像 MEV 区块构建这样的高风险对抗环境，我们不能盲目信任主机操作者，POE 应被视为基线，而非上限。为了完全缓解供应链攻击和恶意内部人员，我们最终需要朝着无信任 TEE 方向发展，这减少了硬件制造商在建立硬件信任根方面的重要性。具体方向包括依赖物理不可克隆函数 (PUF) 进行根密钥生成、构建可验证的硬件和软件栈，以及尽量减少对链条中单个参与方的信任。另一种模型是垂直整合，由单个实体控制硬件制造、配置和运行时完整性——苹果用于 Private Cloud Compute 的硬件完整性生命周期 说明了这种方法，尽管它无法实现独立的第三方验证。

无论选择哪条路径，今天的云证明仍然是一个时间点快照。将基于清单的所有权证明（如 POE）与持续的运行时保证（如 DCEA 的测量启动绑定）相结合，指向了一个自然的扩展方向——无信任 TEE 架构——我们认为这值得社区进一步研究。

致谢。我们感谢 Moe、Quintus、Peg 和 Sarah 对本文早期草稿的深思熟虑的反馈。他们的评论既加强了技术论证，也改进了阐述。当然，任何遗留的错误都是我们自己的责任。

• 原文链接： writings.flashbots.net/m...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～