我们应该将硬件排除在区块链之外吗？

我们应该将硬件排除在区块链之外吗？

你可能认为区块链技术与硬件之间几乎没有关系，除了挖矿之外。毕竟，从比特币到以太坊，区块链的实际功能都是软件定义的。基于硬件的解决方案通常更中心化。然而，在寻求更多企业所需的私密用例、去中心化金融和其他区块链原生应用时，我们可以设计出一种在可扩展性与机密性之间取得最佳平衡的解决方案，同时仍然保持无信任。这可以通过仔细结合区块链的软件属性和硬件创新来实现。

基于 TEE 的区块链机密性

Phala Network 提供全球私密计算云。它可以用作保密智能合约的平台。它们与以太坊等网络上的“传统”合约不同，在于 Phala 智能合约在 CPU 中的一个特殊硬件保护区内运行，即 可信执行环境(TEE)。在 TEE 内运行的程序高度隔离，使用其硬件加密的 RAM。恶意攻击者既无法在未授权的情况下读取内存中的数据（即存储在同一 TEE 内，仅对设备本身可见的加密密钥），也无法操纵程序以产生任何意外行为。

在 Phala Network 中，我们称支持在 TEE 内运行的程序为“pRuntime”。pRuntime 是运行时环境，简而言之是一个“操作系统”，维护 TEE 内的基本 TEE 矿工和看门人协议。它处理 TEE 远程认证、链上注册、密钥管理和机密合约执行。

但是，如何说服用户相信正在 pRuntime 内运行的智能合约并不只是一个不提供任何真实数据安全的模拟器呢？这就引出了核心概念：远程认证。

远程认证

“托管保护区的应用程序也可以要求保护区生成报告，然后将此报告传递给平台服务以生成反映保护区和平台状态的一种凭证。该凭证称为报价。随后，该报价可以传递给平台外的实体并进行验证……”

远程认证是确保 TEE 系统安全的关键。引自英特尔，它证明某段特定代码（通过代码的哈希值进行测量），可选地带有某些由代码生成的定制数据，正在一个最新的、真实的 Intel SGX 保护区内运行。

密钥供应

远程认证是保密智能合约的基本构建模块。但如果我们无法在用户与 TEE 之间建立端到端的安全通信通道，那么它不会太有用。英特尔 SGX，当前 Phala 唯一支持的 TEE，还提供了一种 密钥供应 协议来优雅地解决这个问题。

通过采用密钥供应协议，可以建立从用户到 pRuntime 的信任链：

1. 区块链拥有标准 pRuntime 代码的哈希值
2. pRuntime 运行远程认证协议，获得一个报告，其中包含数据：已认证代码的哈希（即 pRuntime 本身）；和一个临时身份密钥对的公钥
3. RA 报告提交给区块链并在链上进行验证
4. 区块链与 RA 报告中的哈希进行比较（这意味着：参与者是在该 TEE 中的标准 pRuntime）
5. 身份公钥在区块链上注册（意味着：只有当前的 pRuntime 才能控制该身份密钥）

因此，只要消息由身份密钥签名，它必须由注册的 pRuntime 生成。用户可以进一步与 pRuntime 建立类似 TLS 的连接，通过其注册的公钥。

要与 TEE 进行通信，用户可以从区块链上获取特定 pRuntime 的公钥（来自 TEE 注册）。然后，用户可以使用其基础账户的公钥来运行 Diffie-Hellman 协议。它为用户和 pRuntime 之间的通信导出一个密钥。

上述所有步骤都是由 Phala 自动化执行，并快速处理。

随着信任链的建立，这也意味着身份密钥足以唯一表示 pRuntime 的身份。因此，单个远程认证可以在没有 TEE 硬件漏洞的假设下，保护与 pRuntime 的所有未来通信（这将在稍后讨论）。

升级怎么办？

链上升级是一个关键要求，因为它大大降低了通过硬分叉升级造成的安全风险。Substrate 原生支持链上运行时升级。通过区块链上的所谓治理 pallet 来完成此操作。在 TEE 方面，运行时同样可以升级。

在升级 pRuntime 时，我们需要将新 pRuntime 版本的哈希提交给区块链。然后社区可以审查代码、讨论并通过 Phala 上启用的链上治理流程为升级投票。

在 Phala 中，两类节点操作员：看门人和矿工，必须在新的版本在链上被接受后升级 pRuntime。对于矿工来说，这比较简单，因为他们可以简单地停止挖矿，进行升级，然后重新开始挖矿。因为矿工并不要求始终在线。看门人需要较高的可用性要求。因此，他们要么运行另一个带有更新 pRuntime 版本的 TEE 客户端，并在下一个选举周期中等待自然的看门人集轮换，要么进行紧急加密转储其最新状态，并恢复到新的 pRuntime。

尽管在转储状态时存在数据丢失的风险，但在紧急情况下仍然有用。SGX 提供了一个 “密封到保护区”的功能，可以生成只能由相同保护区解密的密文，从而有效地实现这种紧急迁移。

为了减轻硬件安全攻击的风险，看门人节点中的密钥通过 舍密耳密钥共享 方案分发，这意味着即使 TEE 密封被破解（这是一种极端情况——见下文），主机仍然无法在与其他看门人节点达成重大共谋之前获得原始密钥。

攻击与防御

我们的威胁模型部分假设 TEE 制造商可以被信任。这是合理的。首先，他们不知道他们的硬件将如何使用，因此无法提前计划攻击，从而显著降低了风险。第二，如果受到所谓的 零日攻击 影响，在该 CPU 上运行的其他应用程序（在 TEE 外部）通常也处于风险之中。

此外，我们确实看到了过去对 TEE 的实际硬件攻击——到目前为止，主要是来自计算机科学研究者的理论性攻击。幸运的是，这些漏洞通常可以通过几种方式缓解。

通常人们认为软件漏洞是可以打补丁的，而硬件漏洞则无法修复。这并不总是如此。CPU 可以通过微码更新进行修补。鉴于英特尔 SGX TEE 架构的特定设计，绝大多数漏洞都可以修复。最近发生了一次名为 SGAxe 的攻击，它通过 微码升级 以及随后的一次密钥轮换进行了修复。在密钥轮换和撤销之后，所有过时的设备都被远程认证拒绝，这有效地认为这些脆弱设备已经被破坏。重要的是，微修补程序发布得很快，我们不知道发生过任何与 SGAxe 相关的现实违约。

但你可能会问，如果有人仍然发现零日硬件漏洞怎么办？假设该漏洞需要物理访问才能利用，正如 其他一些论文 所建议，矿工可能能够从保密合约中窃取数据。为了缓解这种情况，我们将随机性引入 Phala。区块链在每个周期中随机将矿工分配给保密合约。每个周期后，矿工将进行重新洗牌。只要恶意方没有控制大多数矿工，这种攻击就是不可能的。此外，进行攻击的成本将非常高，因为这需要持续控制网络相对较长的时间。

在最坏的情况下，如果保护区完全被破解，暴露出可供攻击者访问的机密数据并允许攻击者任意操纵执行，我们仍然不想放弃保密合约的正确性。为了使区块链能够区分操纵的执行与真正的执行，我们允许在多个矿工设备上复制智能合约。

复制因子不会影响执行，因为所有输入都是由用户路由并由区块链排序，因此是确定性的。然而，如果存在多个副本，多个 TEE 将尝试将更新的智能合约状态提交回区块链。在这种情况下，将会有一个简单的链上投票过程。我们要求简单多数来“最终确认”状态。

通过在 TEE 基础的智能合约执行中增加复制，而其它情况下不需要进行增强信任属性，我们保持了类似于 Polkadot 的验证者基础的安全回退模型。攻击者必须控制足够数量的矿工才能破坏正确性，即使 SGX 的安全模型完全崩溃。

最后，我们计划增加对其他 TEE 硬件的支持，例如 AMD SEV 和 Arm TrustZone。如果其他芯片制造商跳入竞争以消除英特尔在这一新兴硬件领域的霸权，我们将迅速采用他们，以确保 Phala 的可靠性和抵御任何攻击的能力。

总结

迄今为止，区块链在架构上仅仅是基于软件的。然而，缺乏机密性长期以来都是大规模采用的限制。借助硬件和精心设计的协议，我们解释了构建一个安全且可扩展的保密区块链以供个人和企业级使用是可能的。只有具有透明运行时代码库的公共区块链，以及足够去中心化的矿工和看门人集合才能实现这一点。而这正是我们在 Phala 中正在构建的东西。

Phala 日历

• 即将到来 测试网活动（以及一个秘密的小游戏）
• 6.28 与另一个著名项目的 AMA
• 7.5-7.6 参加由杭州市政府和 8bit 共同举办的杭州区块链周。

关于 Phala

一个基于 Substrate 的保密智能合约区块链，在此基础上可以开发保密和隐私优先的区块链应用。 Substrate Builders Program 起始阵容的一员。获得 Web3 Foundation Grant 。

网站 | 推特 | Github

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