ERC-733：标准化硬件 Enclave 与以太坊的接口

TL;DR: ERC-733 是一项由 @sparsity_xyz 和 Teleport 牵头、众多生态参与者协作推进的成果，其中包含了我们团队的工程见解，以及 @OasisProtocol、@PhalaNetwork 和更广泛的 ERC-8004 工作组的贡献。它为 TEE 与 EVM 的协同处理引入了共享标准，在证明、复制和互操作性层构建了机密执行的结构。@AutomataNetwork 与该框架紧密结合，提供了实现该标准所需的链上验证基础设施和可复现操作系统。

任何构建过连接安全硬件 Enclave 与智能合约基础设施的人，都深知其中的不便之处。每个项目都在发明自己的一套方法来验证代码、管理加密密钥以及与外部网络通信。由于各团队孤立地重复解决相同问题，其解决方案在局部虽能满足需求，却缺乏兼容性。

ERC-733 强制要求可见性。它并不试图重新定义 TEE 或以太坊的底层原语，而是专注于两者之间的接口——这正是大部分复杂性产生之处。ERC-733 将架构划分为证明层、复制层和互操作性层，分别对应信任建立、维护和扩展的关键环节。

工程化证明层

ERC-733 以一种使相关假设显式化并尽可能将其最小化的方式，将证明过程形式化。证明通常被视为 Enclave 本身的属性，但在 TEE–EVM 系统中，它必须被视为一种链上原语。直接在以太坊上验证此类证明文档需要巨大的计算量，由于网络缺乏对硬件供应商所用特定签名曲线的原生支持，其开销常常会超出区块 Gas 限制。

我们在 Automata Network 开发验证基础设施时，就切身感受到了这种不便。为了使链上证明在经济上可行，生态系统需要优化的验证方法。将硬件供应商的证明材料直接缓存在区块链上，或将验证逻辑卸载到零知识证明，是任何生产级应用的现实需求。我们对 Intel DCAP 和 AWS Nitro Enclaves 的 Onchain PCCS 及零知识证明器的实现，正是 ERC-733 证明层所需优化的具体体现。若无这些降低成本的手段，持续的链上验证将仅停留在理论层面。

管理状态与互操作性

一个 Enclave 经过验证后，很少会单独运行。去中心化网络需要能够水平扩展、从基础设施崩溃中恢复，并执行常规软件升级。复制层规定了这些安全 Enclave 之间如何传递加密密钥和应用状态。只有在能够完美认证接收方 Enclave 的前提下，才能安全地复制秘密。

在 Automata，我们构建了一个可复现操作系统，以标准化工作负载的定义和执行方式。Automata Linux 摒弃了笨拙的链下 API，采用了一种严格的注册表方法，这完美契合了 ERC-733 的理念。我们将系统身份分解为基础镜像注册表、工作负载注册表和有时限的会话注册表。这种结构确保智能合约仅授权将秘密复制给那些在运行时能证明自身准确、规范身份的机器。这将其指定为与外部世界交互的唯一安全环境。

互操作性层则进一步定义了这些隔离环境如何与外部 Web 服务和区块链建立安全连接。应用程序必须在硬件 Enclave 内部直接安全地终止加密网络连接，以防止宿主机操作员拦截或篡改外部数据流。

安全阶段与去中心化之路

ERC-733 最关键的贡献在于其安全成熟度模型，该模型将项目从阶段 0 到阶段 3 进行分类。目前，许多应用处于阶段 0，即作为早期原型运行，开发者保留最终控制权，并可能提取资金或操纵执行流程。对于处理真实价值的生产环境而言，这是不可接受的。

一个稳健的应用必须达到阶段 1，确保系统在密码学层面是防开发者篡改的。在此阶段，可验证的证明能防止创建者在没有透明链上通知期的情况下，秘密修改代码或访问敏感数据。要达到阶段 2 和阶段 3，则需要将信任完全分散到多个硬件供应商和去中心化治理系统中。标准化这些阶段使得用户能够准确评估风险，而非仅仅依赖关于“无须信任计算”的市场宣传。

强化链下计算的未来

推进以太坊生态系统的发展，需要的不仅仅是理论设计，更需要经过实践强化的基础设施，以标准化信任并消除应用开发者的不便。参与塑造 ERC-733 的讨论，直接契合了我们为硬件 Enclave 构建实用、可扩展验证系统的使命。通过采用共享的证明、复制和安全评估框架，开发者最终能够构建出既保密又恪守底层区块链网络无须信任原则的应用。

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