SGX：multi-prover的潜在解决方案

1. 引言

尽管ZK-Rollups、电路和SNARK非常复杂且不够成熟，但使用multi-prover方案可对冲证明系统、架构和实现中错误和漏洞的风险。

所谓mulit-prover是指：

• 多种不同类型的proofs。

multi-prover的实现：

• 可采用不同的证明类型（如validity proofs和fraud proofs）
• 可采用不同的证明系统（如SNARK和STARK）
• 可为由不同的团队做的不同代码实现。

本文基本结构为：

• 采用multi-prover的意义，并简要解释了除证明系统之外的其他方法可多样化。
• 阐明了何为SGX（validity proof的一种），SGX的工作原理，以及为何SGX是现有密码学和经济系统的可靠补充选项。
• 如何将multi-prover用于节点和智能合约。

2. 采用multi-prover的意义

single-proof方案存在如下问题：

• 代码风险问题：电路复杂且笨重，尤其是zkEVM电路有数十万行代码。其将在很长一段时间内都可能存在bug。可能在证明系统、电路编译器、zkEVM代码中都存在bug。
• 年轻的密码学原语：zkRollups依赖于SNARK，SNARK还很年轻，且在证明系统中也可能存在bug。

对应的解决方案为：
multi-prover：对单个区块生成多种proof类型。若有bug，即使某种proof被破解，其它proof大概率不会有完全相同的漏洞。若一种proof类型使得某区块无法验证通过，则链可停止（具体取决于可接受的要求是否为true）。附加要求多种proof类型有助于严格改进安全。

2.1 心智模型

可将multi-prover，类比为以太坊客户端多样性：

• 客户端多样性可帮助链“抵御网络中的部分故障，然后恢复并finalize”。

正如Vitalik在其2023年5月博客How will Ethereum’s multi-client philosophy interact with ZK-EVMs?中所述：

• “以太坊的多客户端哲学是一种去中心化，就像通用去中心化，可关注架构去中心化的技术利益或政治去中心化的社会利益。最终，多客户端哲学是这2种利益的动力，也为这2种利益服务。”

同理，Rollup multi-prover哲学为：

• 为技术利益和社会利益构建架构去中心化和政治去中心化：
  • 技术利益：即采用不同的证明系统、架构和代码实现。
  • 社会利益：即power（权力）多样性，避免权力集中在单个链团队。

2.2 multi-prover结构

multi-prover可涵盖：

• 不同的证明类型：如在optimistic rollup（中使用的欺诈证明fraud proofs）和在zkRollup（中使用的有效性证明validity proofs）。由于fraud proofs和validity proofs 依赖于非常不同的假设，且二者的设计彼此相距甚远，因此欺诈证明中的错误与有效性证明之间的错误相关性非常低。证明系统多样性有一种不太流行的选择——SGX，为validity proofs中的一种。
• 不同的证明系统：如若使用zk validity proofs类型，后端可为SNARK或STARK。
• 不同团队的不同代码实现：这可减少单软件中的某个bug导致整个网络发生灾难性故障的风险，因其他团队编写的其他软件不包含相同bug 的可能性很高。

2.3 proof被破解风险

若有多种证明类型，即意味着在做区块证明时，存在一定的概率有不同的输出。

proofs通常期望其具备2大属性：

• 完备性completeness：即若statement为true，则prover总是能让verifier信服该事实。
• 可靠性soundness：即若statement为false，prover没法试图作弊来让verifier信服该statement为true。

对于validity proof类型：

• 在完备性上破解proof是指：无法为某有效区块生成proof。即意味着，无相应的validity proof提交上链。
  • multi-prover场景下，取决于所需的proof类型数阈值n/N，链可能会halt。
• 在可靠性上破解proof是指：某有区块的多个proofs可对应有不同的区块hash，事实上，应仅有一个正确的区块hash，从而仅有一个proof是对的。
  • multi-prover场景下，若将某有效proof提交上链，需约束该proof对应的区块hash，必须与其他类型proof的区块hash匹配。
    • 若多种证明类型具有相同的bug，且可为同一区块的同一incorrect blockhash生成多种不同类型的proofs，则此时multi-prover配置也将被破解。

对于fraud proof类型：

• 在完备性上破解proof是指：无法为某无效区块生成fraud proof。
• 在可靠性上破解proof是指：为某有效区块生成了fraud proof。

当同时使用validity proofs和fraud proof这2种类型时，二者之一若出现完备性问题，则可通过多签治理来作为紧急应对措施。治理机构可检查哪个区块哈希是真实有效的，并在链上确认，必将有问题的proof类型除外或升级。此时，好的multi-sig是必须的，详细可见Ed Felten twitter讨论。

若有两种以上的证明类型，则可采用少数服从多数原则来解决争议。同时将有错误行为的provers除外或更新。

3. 什么是SGX？SGX工作原理？SGX优缺点

当讨论到证明类型多样性时，可组合不同的validity proofs（如zk proofs 和 SGX proofs）和 fraud proofs。不过fraud proofs需要较长延时，不太满足zkRollup场景。为此，本文重点讨论SGX proofs。

3.1 什么是SGX？

所谓SGX：

• SGX表示Software Guard Extensions。
• SGX是英特尔制造的一种可信执行环境（TEE，Trusted Execution Environment）。
• TEE是设备主处理器上与系统主操作系统（OS，operating system）隔离的一块区域。TEE可确保数据在安全的环境中存储、处理和保护。
• SGX使应用程序能够在自己的可信执行环境中执行代码并保护secrets，从而提供免受恶意软件攻击的保护。
• 在区块链中，SGX可用于私人智能合约。当其在可信飞地内运行时，就变得私有。如，可在SGX内部运行oracle以获得隐私并在不透露所证明内容的情况下进行证明。
  
• SGX创建从系统的物理RAM保留的隔离的（代码和数据）不可寻址内存区域（enclaves，飞地），然后进行加密。换句话说，飞地是一个“秘密基地”，它同时包含代码和数据，应用程序可在其中处理敏感数据而不会暴露其风险。
• 加密发生在硬件层，可防止基于软件的攻击。即使黑客可以访问该应用程序、整个操作系统以及 运行TEE系统的BIOS，机密数据将保持secret。

3.2 SGX组件的高层概述

SGX关键组件有：

• TCB（Trusted Computer Base）：为操作提供安全环境的计算系统中的所有内容。这包括其硬件、固件、软件、操作系统、物理位置、内置安全控制以及规定的安全程序。
• Hardware secrets：包括：
  • RPK：Root Provisioning Key，由Intel随机创建和保留。
  • RSK：Root Seal Key，生产过程中在CPU内自动随机生成。
• Attestation：证明软件可执行文件已在平台上正确实例化的过程。
• Remote Attestation：使远程方可以确信预期的软件在完全修补的、支持Intel SGX的平台上的飞地中安全运行。
  
• Sealed storage：一种密码学数据保护工具，可以将秘密数据保存到不可信介质中。sealer可指定 可访问数据的软件环境的限制。Sealed storage工具将在显示受保护数据之前，会检查请求软件的身份是否符合之前sealer操作中指定的策略。

3.3 SGX工作原理

SGX应用程序分为两个部分

• 可信部分
• 不可信部分。

SGX的工作流程为：

• 1）应用在可信部分中申请创建一个飞地。
• 2）应用调用可信函数。可信函数是由软件开发人员创建的用于在飞地内工作的代码。只有可信函数可运行在飞地内，其它所有从飞地外部试图访问飞地内存的尝试都将被处理器拒绝。
• 3）一旦对可信函数调用后，应用就允许在可信空间内，且可 以明文方式查看飞地代码和数据。
• 4）当可信函数返回是，飞地数据仍保持在可信内存中。
• 5）然后该应用程序将在不可信空间中继续运行。
  

其中:

• Untrusted code is an application. 不可信代码为某应用。
• 调用ecall函数进入飞地。
• ecall函数的输入是不可信的。
• 可信代码为某飞地。Trusted code is an enclave。
• 在ecall中调用ocall来call outside。
• ocall的输出是不可信的。
• 飞地不能直接访问OS提供的服务。
• 有2个关键密钥：私钥和公钥。
  • 私钥：在飞地内生成，且永远不会立刻飞地。
  • 公钥：可对任何人可见。用户可用公钥来对消息加密，从而仅飞地可解密出相应消息。

3.3.1 Attestations

由于数据交换或通信等不同原因，飞地有时需要与同一平台上的其他飞地协作。

需要Attestations的两个主要情况为：

• 1）两个交互飞地必须相互证明其是可信的。
• 2）客户端必须向服务器证明，客户端应用程序正在可安全处理机密的可信平台上运行。

这两个案例都需要a proof of secured execution environment，而Intel SGX将此证明过程称为 Attestations。

Attestations有两种类型：

• local attestation：一个飞地使用Intel SGX Report机制对另一个飞地进行本地身份认证，以验证对方是否在同一TCB平台上运行。

• remote attestation：remote attestation的目标是使硬件实体 或 硬件和软件的组合，获得远程服务提供商的信任，这样服务提供商就可以放心地向客户提供所请求的secrets。remote attestation验证了三件事：

  • i）应用程序的身份
  • ii）应用程序完整性（尚未被篡改）
  • iii）应用程序正在启用Intel SGX的平台上的飞地内安全运行。

  借助Intel SGX，Remote Attestation软件包括：

  • 应用程序的飞地
  • Intel提供的Quoting Enclave（从其他飞地接收REPORTs，验证并以attestation key签署这些REPORTs，然后再返回结果）
  • Provincing Enclave（用PSK加密attestation key，并存储在平台上供后续使用）

  attestation Hardware为启用Intel SGX的CPU。有关详细的remote attestation架构，参看SGX 101。

remote attestation功能要求该服务必须在Intel Attestation Service 中注册，或使用其它（如某云服务提供商）安全管道定制服务。

对于区块链SGX，即使remote attestation不如local attestation强健，但remote attestation仍是唯一选项。

3.4 SGX的疑问、限制和弱点

使用SGX存在如下疑问、限制和弱点：

• 1）信任

  • 使用SGX，需相信英特尔的这一奇特技术一切都很好。由于硬件已经与可信飞地内的私钥一起交付。此外，英特尔更新新攻击补丁的速度相当缓慢。可登录sgx.fail 查看英特尔目前仍未修复的公开SGX攻击列表。
    作为对此问题的反驳，有人提到今天英特尔的声誉是一种极高价值的资产。也就是说，对于英特尔而言，使用SGX进行的任何恶意操作在经济上都是不合理的，至少对于个人经济利益而言。
  • 另一个问题是，由于SGX在2021年对消费类CPU进行了deprecated，未来也可能在其它版本CPU中进行deprecated或大幅修改，从而可能与特定用例不兼容。

• 2）全新的技术
  几乎没有人能公平地回答SGX的可靠性问题。
  最公平的答案是：我们不知道，因为它很新，我们也不知道所有可能（且将要）发生的攻击。
  大多数SGX是黑匣子，大部分以ucode实现。

• 3）安全性
  仅TEE是不够的。因此还需要由MPC、ZK、FHE、ORAM等（以及它们的不同组合）进行补充，以确保TEE安全。
  除了将SGX与其他密码学原语结合使用之外，还可将其与经济激励相结合。
  SGX vs. 经济学：详情见2023年3月视频Why TEEs suck both less and more than you think, Phil Daian | ETHDenver Privacy Workshop：
  
  在某些方面，SGX弱于经济激励措施，某些方面又强于：

  • SGX更强的方面：
    在尖锐的分布情况下，经济学会达到极限。如，在级联经济学崩溃的情况下（如Terra），当经济系统安全依赖于其他经济系统时。当其它经济系统的安全性取决于经济假设。若某经济体系的假设被打破，那么所有依赖它的经济体系也将被打破。对于SGX，其安全性基于技术假设，而不是经济假设，因此认为SGX更强大。
  • SGX更弱的方案：
    SGX仍然可被破解。一个完美的情况是将SGX与经济激励措施结合起来。“将这些元素的成功组合，取决于破坏它的边际成本。若“preparation stage”（如给博士很酷的工作，买很好的硬件），和“execution stage”（折中每个额外的SGX单元），将是非常昂贵的。但对于SGX本身来说，这不是问题。每个新的SGX攻击是便宜的（未来可能会修复该问题）。

• 4）作弊
  当某些事物是私有的（如SGX）时，可能会发生巨大的但无法察觉的作弊行为。
  因此，SGX不是神奇药丸。但是，飞地会显着降低攻击表面，因此使用它似乎是合理的。
  见2022年论文Confidential Computing in Cloud/Fog-based Internet of Things Scenarios：
  
  最合理的策略是以智能方式将所有解决方案（包括密码学解决方案和经济解决方案）组合在一起，以获得真正强大的解决方案。

3.5 现有的区块链实现

当前SGX有多个SDK实现：

• 英特尔SGX SDK
• Open Enclave（C++）
• Rust SGX
• Teaclave等

在不修改源代码的情况下孤立运行现有应用程序libOSes（将整个操作系统实现为一个库），当前已开发了：

• Gramine
• Occlum
• EGo

为希望在类似Linux的环境中运行的应用程序提供了抽象层。

Flashbots和Nethermind的共同努力开创了区块链区域内的SGX实现：

• 1）在SGX中运行geth：在SGX中运行Geth是完全可能的，但这是个耗资源又耗时的过程。它需要大量的内存，启动时间约为3个小时，状态很容易丢失。
  当前的问题和限制为：

  • 存储状态：Gramine的加密文件mounts性能较慢，使得Geth难以跟上以太坊主网（也可能是个bug）。
  • 初始同步：链的初始同步过程可能需要很长时间，且当前需要高达800GB的存储空间。
  • 信息泄漏：当主机系统可以提取有关在SGX飞地中正在访问哪些数据的信息时，就会发生信息泄露。对于Geth，由于IO和内存访问模式，有可能泄漏有关从数据库访问的密钥的信息，具体见2021年论文SGX-MR: Regulating Dataflows for Protecting Access Patterns of Data-Intensive SGX Applications探索了IO泄漏问题。

  针对以上问题，Flashbots尝试将整个链存储在内存中。但这会带来新问题：

  • 要求系统至少具有1TB内存，对应的硬件资源密集且价格昂贵。但是，应用程序并不需要立即访问所有1TB内存，其中许多可以由SGX内核驱动程序加密并swapped out。
  • 若Geth应用程序停止，则状态将丢失。
    
  • 详细的代码和工具见：https://github.com/flashbots/geth-sgx-gramine
  • 相关讨论见：Running Geth within SGX: Our Experience, Learnings and Code | Flashbots

• 2）SGX内构建区块：其目标为实现：私有交易 + 去中心化builders。

  • 区块builders，以及其他基础设施提供商，不再可看到用户交易内容，且运行的是verifiable block construction algorithms。
  • 展望未来，SGX内部的builders可制作出可证明有效的块，并如实报告其出价大小，从而可能无需mev-boost relayer。

  当前的问题和限制为：

  • Geth状态大小：geth数据库需要大约1TB的存储空间。启动过程大约需要4.5个小时。实现的解决方案：将古老的数据库保留在飞地之外，减半到~ 500GB的状态存储在飞地内。具体细节见feat: save memory, store ancient-db on hostfs #10。
  • 合并性能和额外的延迟：SGX builder当前性能为~ 150 mgasp（Million Gas Per Second），约为非SGX builder性能的一半。
  • “造成这种降解的一个可能罪魁祸首是Golang处理syscall的方式。Golang不使用libc syscall接口，而是直接调用内核。在SGX飞地内运行时，这会产生额外的执行开销。可以通过使用gccgo构建geth来进行可能的改进。”

  有关Flashbots实现的更多信息见：

  • Flashbots论坛 Block Building inside SGX
  • Alex Stokes的distributed block building (and exploring the builder design space, broadly) #139

3.6 将SGX应用于Rollup

Rollup仅对验证区块的正确执行感兴趣。这意味着可创建一个无状态程序，该程序仅验证块的正确执行。可以从正常节点查询执行此操作所需的所有数据。该数据作为输入传递给程序，程序验证其正确性。这正是zk proofs的工作原理，因为zk proofs无法直接访问状态。

更具体地说，输入是最新的已知状态根、交易列表和区块参数。预期输出（区块哈希）也作为输入传递，因此可根据预期值检查程序计算出的区块哈希。要验证作为输入传递的状态数据，该输入还包含区块内访问的所有状态的默克尔证明，以便可根据已知状态根对其进行验证。这样，只要可确保将正确的状态根和区块数据提供给无状态函数，SGX就可以证明程序的正确执行，从而证明区块的正确执行。

3.6.1 multi-prover在rollup中的工作方式

任何有兴趣生成证明的人都将希望为，需要为其创建证明的链，运行一个节点。从该节点中提取用于生成证明的所有必要数据。除了区块中的交易之类的明显数据之外，还包括所有状态访问的所有Merkle证明。对于zk proofs，这也可能包括区块中所有交易的execution trace。根据这些数据来生成证明。生成基于zk的proof，可能需要使用多台机器，用时数分钟。SGX proof则仅在单个机器上运行，仅需要数秒钟。

一旦所需proofs均已生成，则可将其一起提交给rollup智能合约。这些proofs不会分开提交，因为仅具有一些必需的链上proofs是没有好处的。只需将所有proofs一起提交，从而让事情变得更容易高效。借助链上的所有proofs，智能合约可验证它们的正确性。

• 对于zk proof，这意味着在zk proof上运行verifier。
• 对于SGX proof，则只需检查包含预期数据的某些ECDSA签名是否由预期地址签名。

若所有proofs都验证通过，且给出了预期的proofs数量，则唯一需要检查的是所有proofs实际上证明的是具有相同区块哈希的区块。若检查通过，则将该区块最终标记为proven，其区块哈希链上已知（假设之前所有区块也是proven，使得该区块是基于正确的链高度上生成的）。

参考资料

[1] Taiko团队2023年9月博客Why multi-prover matters. SGX as a possible solution.