威胁模型与信任假设

OXN 的机密性保证建立在硬件认证 TEE 上。本页说明这意味着什么：OXN 防御哪些攻击者、不防御哪些攻击者，以及远程认证如何让这份防御变得可验证。

不是所有威胁模型都需要 OXN，也不是所有需要 OXN 的威胁模型都能被任何机密链很好地服务。在做决定前先读它。

信任锚点：Intel SGX + 远程认证

OXN 的机密性假设：

Intel SGX 正确实现了内存隔离。 CPU 把 enclave 内存保护到操作系统、Hypervisor 以及机器上其他任何进程都看不到。
Intel 的认证服务是诚实的。 当一个 enclave 产出一份说"我正在真实 Intel CPU 上运行代码 X"的认证 quote，这份 quote 可以被 Intel 的公钥验证。
具体的 enclave 二进制就是你预期的代码。 认证 quote 里包含加载到 enclave 中代码的 measurement（哈希）。验证者会把它与公开的期望 measurement 对比。

这些都不是 OXN 独有的新假设。它们是 Intel、Microsoft、Google 等等在其上构建产品的标准 SGX 威胁模型。

恶意节点运营方。 节点跑 OXN，运营方想读你的交易或状态内容。已防御。 enclave 只在受保护内存中解密输入、存储输出。运营方看到的是密文。

恶意云厂商。 节点跑在 AWS / Azure / GCP，云厂商想 snapshot 内存或以其他方式窥探执行。已防御。 SGX 防御 Hypervisor 层攻击，包括内存快照。

恶意 RPC 提供商。 你对话的公共 RPC 是恶意的，想读传输中的交易内容。已防御。 Calldata 是从你的客户端到 enclave 端到端加密的——RPC 提供商只看到加密信封。

被动网络观察者。 有人在网线上被动抓包。已防御。 同一份加密；穿过外层 CBOR 信封之后的流量对他们是不透明的。

索引器或区块浏览器。 任何读取链上公开数据的一方。对于加密内容已防御。 他们看到交易元数据（from / to / gas / status），但看不到 calldata、返回数据、事件内容或存储。

仔细读这一节。如果其中任何一条落在你的威胁模型里，你需要在 OXN 之上再加东西。

被攻陷的 Intel CPU 或 SGX 漏洞。 OXN 信任 SGX。如果 Intel 或研究人员公开了破坏 SGX 隔离的 0day（多年间已有多次——Foreshadow、Plundervolt、ÆPIC 等等），机密性可能在补丁发布前被打破。所有基于 TEE 的链都有这个风险。

侧信道。 SGX 不防御 CPU 封装内的时序、缓存、功耗侧信道。有能力本地接触验证节点机器的高级攻击者可能通过观察执行模式抽取信息。合约应尽量避免数据依赖的分支——见机密性陷阱。

被攻陷的客户端。 如果你笔记本上的恶意软件读了你的私钥或进程内存，没有任何链能保护你。OXN 的保证从加密交易信封开始，之前的部分是你的责任。

元数据分析。 即便内容加密，"谁在什么时候调用了什么合约"这个模式是公开的。如果只有你在凌晨 3 点 UTC 调用某个特定合约，这个模式与加密无关，会泄漏信息。

合约正确性错误。 OXN 不校验你的 Solidity 是否正确、安全、无逻辑漏洞。所有存在于以太坊的 EVM 安全问题也存在于 OXN。机密性不能替代审计。

被强制披露。 如果法院要求你公开一笔交易的内容、而你持有会话密钥，你可以公开。OXN 不提供合理否认。

"你的调用在真实的、跑着 OXN 运行时的 SGX enclave 中执行"这个断言是可验证的，不只是假设。

链把 enclave 的公钥和认证 quote 一起分发。Quote 是 CPU 产生的签名声明：

客户端（或 SDK）用 Intel 的 Provisioning Certification Service 验证 quote。只有验证通过，客户端才会用这个 enclave 公钥加密 calldata。

具体来说：wrapped provider 首次初始化时会先拉取并验证一份认证 quote，然后才会加密任何东西。验证失败则加密失败，SDK 报错。

如果你的应用处理真正的机密（私钥、凭证、隐藏游戏状态、未揭示的出价），OXN 的威胁模型就是为你设计的。 打破 SGX 的经济与技术门槛超过大多数应用层威胁。

如果你的应用被具备 SGX 级攻击投入的国家级对手针对，OXN 单独不够。 考虑叠加 ZK 证明、多方计算、或你自己控制的链下 enclave。

如果你的应用只是想要"某种隐私"、没有具体威胁模型，OXN 以近乎零开发成本给你相比公开 EVM 的巨大升级。 大多数应用属于这一类。