在对抗性假设下设计 Bitcoin 基础设施
I’m ready to translate the article for you, but I don’t have the full text of the post. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the text, I’ll translate it into Simplified Chinese while preserving all formatting, markdown, and technical terms.
Scaling Bitcoin Infrastructure Exposes a Fundamental Tension
关键操作常常运行在我们无法控制的环境中。在构建签名和执行服务时，我直接遇到了这一点。假设云提供商“基本诚实”在标准工作负载下是可行的，但在涉及私钥、签名逻辑或协议关键操作时就会失效。这不是偏执，而是价值攸关系统中运营安全的现实。
单一信任假设会导致系统脆弱性——这是工程师们能感受到但很少讨论的问题。
典型比特币部署
- 虚拟机
- 容器化服务
- 环境变量密钥
- IAM 策略
这种设置足以满足无状态应用程序，但对高信任组件而言却脆弱。
问题区域
- 托管服务 将密钥暴露给主机内存。
- 共识关键节点 假设运行时是良性的。
- 多签或阈值方案的签名服务 将主机操作系统视为合作的。
- 特定应用处理器 继承相同的盲点。
管理边界、明文密钥以及可变的构建产物共同形成一种隐式信任模型，无法抵御对抗性环境。这些弱点是结构性的，而非偶然的。
执行问题，而非云问题
运营者可能敌对，主机被攻陷，构建被篡改，或配置错误。传统安全侧重于外围加固；对抗性基础设施需要 最小化对运营者本身的信任。
正确的原语是：
- 隔离执行
- 可复现性
- Attestation
可信执行环境 (TEEs)
- 硬件支持的隔离
- 加密测量
- 远程证明
只有在满足可验证条件时，才会释放机密，从而实现一种 实例特定且有条件 的信任模型。这将安全性从希望转向可验证的约束。
警告： 机密计算并非灵丹妙药。它 不能 防止应用层面的漏洞、侧信道攻击或网络 I/O 配置错误。它的价值在于以可衡量、可强制执行的方式降低对运营者的信任。只有当机密计算能够在真实基础设施中经受考验时，它才具有意义。
Terraform 参考实现
为了对这些想法进行压力测试，我开发了一个 Terraform 参考实现，用于在 AWS Nitro Enclaves 中部署比特币敏感工作负载。目标不是生产就绪，而是强迫架构清晰，并提出更难的问题：
当对抗性假设在基础设施层而不仅仅是应用代码层被强制执行时，会发生什么？
为什么选择 Terraform？
- 将 enclave 主机、IAM 边界、网络约束和证明流程编码为声明式基础设施，使隐式的信任决策 显式化。
- 每个资源定义都代表了关于 谁被信任、何时以及在何种条件下 的具体选择。
- 没有抽象或含糊的余地：要么 enclave 能够可重复地启动并完成证明，要么系统拒绝启动。
供应链风险已不可忽视
- 必须在 CI 中 确定性 构建 enclave 镜像，对其进行度量，并以不可变方式引用。
- 不能延迟或假设秘密供应是安全的；它必须 在成功的证明后通过加密方式进行授权，否则部署将按设计失败。
最初作为基础设施代码的东西，演变成直接编码安全姿态的方式，而不仅仅是提供资源。这揭示了一个令人不安的真相：大多数比特币基础设施之所以脆弱 并非因为工程师粗心大意，而是我们的工具鼓励在运行时才做信任决策。将 Terraform 与 enclave 结合使用时，这一动态被颠倒。你被迫在系统启动之前就决定哪些是可信的。
Minimal Parent Process
- 最小父进程在 Nitro‑enabled EC2 实例上作为 untrusted broker 运行。
- enclave 应用在 cryptographically measured, isolated environment 中执行签名操作。
- Terraform 将主机、IAM 边界、网络和 enclave 生命周期进行代码化。
- 引导过程确保 enclave 镜像以确定性方式构建，并根据预期的
PCR（Platform Configuration Register）值进行测量，若完整性检查失败则被拒绝。 - 只有在 attestation 成功后才会提供 Secrets。
关键工程真理
- Enclave 边界强制模块化。
- Attestation 成为一种协议。
- 可重复性是捕捉细微漂移的必要条件。
基础设施代码现在 明确编码安全姿态，而不是将信任决策推迟到运行时。在这些约束下进行设计，使优先级从“安全部署”转向 可验证执行。
- 仅最少的逻辑驻留在 enclave 中。
- 数据流是显式的。
- 信任是按实例获得的。
- 可重复性和 attestation 取代了假设和希望。
持续工作
- 已认证的秘密经纪人
- 确定性的 CI‑构建的 enclave 工件
- 跨‑TEE 比较
- 在不引入隐式信任的情况下扩展 enclave 编排
实际挑战
- 生命周期管理
- 故障恢复
- 可观测性
基础现在是 有原则的。
结论
比特币基础设施只有在赢得信任时才值得信赖。假设运营者是合作的虽然方便，却不安全。机密计算使我们能够设计在对抗性环境中仍具弹性的系统，信任由硬件强制执行，并通过可复现、可测量的执行进行验证。
比特币基础设施的机密计算仍处于早期阶段，许多棘手的问题更多是运营层面的，而非理论层面的。一旦系统超出原型阶段，认证工作流、确定性构建、 enclave 生命周期管理、可观测性以及故障恢复等都会暴露出明显的痛点。
我将继续探索这些领域，尤其是机密执行与现实基础设施约束交叉的地方。如果你正在从事可信执行环境、enclave 或比特币相关基础设施的工作，我很乐意交流并交换想法。
编排、可复现的构建系统，或在对抗性假设下的比特币基础设施——我有兴趣比较经验。
这些系统不会通过孤立的实现而成熟，而是通过共享的威胁模型、具体的失败案例以及细致的工程讨论来成熟。