Phala实现区块链和硬件的“平衡”

或许你会觉得硬件与区块链风马牛不相及。毕竟，从比特币到以太坊，区块链都是软件为王，基于硬件的解决方案往往有中心化的嫌疑。其实，在隐私保护领域，引入硬件是常规操作。硬件是实现实用化的基础，软硬结合的方案可以实现一加一大于二的效果。通过巧妙组合，Phala 可以在让其去信任化的同时，让解决方案在可拓展性和保密性之间达到绝佳的平衡。

#1 基于TEE的区块链保密

Phala Network运用了保密智能合约来实现区块链保密。与传统合约不同的是，它运行在 CPU 内一个特殊的硬件区域（可信执行环境）内。这个区域与其他部件高度隔离；未经授权，包括恶意攻击在内的任何尝试都无法读取TEE中的数据，也无法干预其中程序的执行。

Phala将运行在 TEE 中的程序称为pRuntime。 pRuntime 在 TEE 内维持矿工和 Gatekeeper 节点运行，并负责处理 TEE 远程证明、链上注册、密钥管理和保密合同执行。

然而，如何让用户相信智能合约运行在 pRuntime 里，而不只是一个伪造的 TEE环境？这个时候，我们需要了解什么是“远程认证”（Remote Attestation）。

“An application that hosts an enclave can also ask the enclave to produce a report and then pass this report to a platform service to produce a type of credential that reflects enclave and platform state. This credential is known as a quote. This quote can then be passed to entities off of the platform， and verified…”

“特殊安全区（enclave）里的应用程序也可以要求安全区生成报告，然后将该报告传递到平台服务以生成反映安全区和平台状态的凭证。这样的反馈凭证被称为“引报”（quote）。之后，引报就可以作为信任源向外界验证安全区内应用的可信性……”

远程认证是确保 TEE 系统处于安全和可信状态的关键。来自英特尔的 Quate 可以证明这段代码（以哈希值确定）和需要用到的某些数据都确确实实运行在最新版本的 SGX 安全区内。

#2 Secret Provisioning

远程认证是保密智能合约的灵魂。但如果我们无法在 TEE 和第三方之间建立端到端加密的通信，应用范围就会受到限制。所以，英特尔 SGX 还运用了 Secret Provisioning协议来优雅地解决这个问题。

借助 Secret Provisioning 协议，我们可以建立从用户到 pRuntime 的信任链：

区块链上公示了合法 pRuntime 代码的哈希；

pRuntime 运行远程证明协议，获取远程认证报告，报告中含有：被证明代码的哈希值（pRuntime本身）； 身份认证密钥对的公钥（有时效性）

远程验证报告在链上提交，并在链上进行验证；

区块链比较远程报告返回的哈希值（旨在证明：参与方确实是TEE中运行的合法 pRuntime）

身份认证公钥完成链上注册（以后只有目前正在运行的 pRuntime 可以使用此密钥对）

注册完成后，但凡是由这个身份签名的消息，都一定是由此 pRuntime 生成的。用户可以使用已注册的身份公钥进一步和 pRuntime 建立类似 TLS 的连接。

需要与 TEE 进行通信时，用户可以从区块链获取已注册的 pRuntime 的公钥，并用 Substrate 账户和公钥进行 ECDH 迪菲赫尔曼协议密钥协商，并获得用于和 pRuntime 进行通信的密钥。

信任链建立后，该身份密钥将唯一地表示 pRuntime 的身份。理论上，只要TEE没有硬件漏洞（在后文我们会继续讨论这个点），则一次成功的远程认证就可以确保所有与 pRuntime 往来的通信处于安全和可信的状态。

#3 链上升级

链上升级可以极大地降低硬件升级硬分叉带来的风险，所以非常重要。Substrate 天生支持 Runtime 链上升级，在治理模块即可完成。同理，TEE 里的 Runtime 也是可以升级的。

升级 pRuntime 时，需要将新的哈希提交到区块链上。之后便可由社区通过类似于 Substrate 的链上治理流程来审查代码、讨论并投票赞成升级。

链上一旦有升级，Phala 的守门人（Gatekeeper）和矿工都必须第一时间升级 pRuntime。这个过程对矿工来说会相对容易一些，因为他们不用 24 小时在线，只用暂停挖矿，升级，然后继续挖矿即可。守门人则肩负可用性重任，需尽可能在线，因此他们要么运行另一个新版本的TEE客户端等待下一次选举期间的自然切换，要么对状态数据进行紧急加密转储，然后将其恢复到新的 pRuntime。

虽然后者有状态数据丢失或暴露的风险，但在紧急情况下也不失为一种选择。 SGX 有一个“密封至安全区（Seal to Enclave）”功能，可以生成只能由同一安全区解码的密钥。这个密钥可以确保数据不被任何第三方查看或迁移。为了降低硬件安全漏洞被利用的可能性，Gatekeeper 中的密钥是通过 Shamir 密钥共享方案分发的。即使 sealing 崩坏，如果没有网络中的多方合谋，主机也无法获取密钥。

#4 攻与守

Phala 的威胁模型首先假设TEE厂商是部分可信的。原因有二：一，TEE 厂商在制造芯片的时候并不知道这些芯片会被用在什么地方；二，即便遭受“零日漏洞攻击（Zero-day Attack）”，其他所有运行在芯片上的程序都会有风险，而不单单是TEE承受风险。

虽然秉持上述假设，不可否认的是，硬件漏洞攻击仍然时有发生。好在，有以下几种方法可以解决或处理硬件风险问题。

首先，硬件漏洞是可以修复的。一个常见的误区是，只有软件漏洞可以修复，而硬件漏洞不能修复。事实并非如此，我们可以通过微码来修复硬件漏洞。英特尔为 SGX 设计了一种特殊的架构，大多数漏洞都可以被及时修复。比如，最近新出现的一种名为 SGAxe的攻击就已经通过微码升级和密钥组轮换被修复。密钥经过转置和撤回后，所有非最新版 SGX 设备的请求都将被远程认证驳回。

其次，随机性是一柄利器。有人会问，零日漏洞攻击怎么应对？——矿工拥有硬件访问权限，就可能会利用零日漏洞攻击盗取数据，有作恶的可能。针对这种情况，我们可以活用“随机性”，让区块链把保密智能合约在一个时间段随机分配给不同的矿工，这样，每个时间段的矿工都不同。这样一来，攻击者必须在不同时间段持续控制大多数矿工的TEE设备才能成功，作恶成本会非常高。

最后，保密合约可以通过副本保证执行的正确性。即使在极端情况下，安全区完全被攻陷、机密数据完全暴露在攻击者面前、TEE 内程序可以被任意改写，合约的“正确性”（correctness）仍然可以得到保证。在 Phala 的设计中，保密合约可以有一个或多个副本并行运行。副本不会影响合约的执行，因为所有输入都来自区块链。并行状态下，会有多个 TEE 同时尝试向链上提交状态数据。此时就会有一个简单的链上投票过程，状态数据的“最终确认”（finalize）将遵循少数服从多数的原则。

副本的设计让这个过程变成了类似 Polkadot Validator选举的过程。要想攻击“正确性”，攻击者必须控制绝大多数TEE矿工。——这还是在完全被攻破的极端情况下。

#5 结论

过去，区块链仅限于软件范畴。发展至今，完全公开性已成为大范围落地的桎梏。而有了可信硬件和精心设计的协议支持，Phala将证明和构建出一个可信、可保密、可大范围落地的区块链世界。