在SGX中运行Geth：我们的经验、教训和代码

在 Flashbots，我们正在探索信任执行环境（TEEs），如 SGX，以及其他隐私技术，包括多方计算（Multi-Party Computation）和同态加密（Homomorphic Encryption），作为无信任协作的重要组成部分，沿着交易供应链。这对于去中心化区块生成和共享私密订单流等应用特别相关。

今天，我们很高兴地发布我们的努力和关于在 SGX 内部运行 Geth 的一系列关键经验，以供他人重用、实验和构建。

与 konVera 合作，这是一家在机密计算领域拥有强大专业知识的软件开发公司，我们已成功实现了一个完全可工作的 Geth 原型，该原型在 SGX 内部运行，并与以太坊主网同步。

你可以在 https://github.com/flashbots/geth-sgx-gramine 找到代码。

使用 SGX

历史上，TEEs（如 SGX）的理念是仅将你的应用程序中的一小部分关键部分隔离在 enclaves 之内。为此，有必要调整代码以使其适应 SGX。人们稍后才希望使用 SGX 并在不修改源代码的情况下运行现有应用程序。

为此，开发了诸如 Gramine、Occlum 和 EGo 的 libOS，以为期望在类 Linux 环境中运行的应用程序提供抽象层。我们选择 Gramine，因为它是最成熟和稳定的，并且文档齐全。

问题与挑战

在开始这个过程时，我们遇到了几个必须解决的挑战和问题。

状态存储

我们面临的一个主要问题是 Gramine 的加密文件挂载性能较慢，这使得 Geth 难以跟上以太坊主网的步伐。这可能是一个 bug，应该在某个时候进行调查。

为了解决这个问题，我们尝试使用不同的 libOS 框架，但最终发现这些替代方案并不适合我们的需求：

• Occlum：性能看起来不错，但高度不稳定，我们无法让 Geth 在加密状态下运行（许多系统调用缺失，不稳定，缺乏文档）。
• EGo：易于设置，但比 Gramine 慢得多，并且根本不支持加密文件。

初始同步

链的初始同步过程可能需要相当长的时间，目前需要高达 800GB 的存储。

我们选择将未加密的数据库从主机复制到 SGX，而不是在 SGX 内部运行同步。启动时复制数据库也对数据进行了加密，由于数据大小和加密操作，这个过程大约需要 3 小时。

信息泄漏

我们探索的另一个问题是信息泄漏的问题，即当主机系统能够提取有关访问SGX enclave内数据的信息时发生的情况。在 Geth 的情况下，由于 IO 和内存访问模式，这可能会泄漏有关访问数据库的密钥的信息。

这篇研究论文更详细地探讨了 IO 泄漏问题：“ SGX-MR: Regulating Dataflows for Protecting Access Patterns of Data-Intensive SGX Applications ”（Alam, Sharma, Chen, 2021）

内存中方法

鉴于这些挑战，我们决定尝试不同的方法：将整个 Geth 数据库存储在内存中，并使用加密交换空间使该方法的资源占用降低。

要在内存中存储整个链，我们需要至少 1TB 的内存，这在硬件上资源密集且成本高。该方法的另一个缺点是没有持久性，如果 Geth 应用程序停止，则状态会丢失。

幸运的是，并不需要 1TB 的所有内存都同时被应用程序访问，许多内存可以由 SGX 内核驱动程序加密并调出。

我们最初的尝试是在一台 384GB 的机器上运行 Geth，该机器具有 256GB 的 EPC（SGX 保护）内存和 1TB 的交换空间，效果良好（约 150 mgasps [百万 gas 每秒]）。但这些机器昂贵且难以获得（仅限于 Azure）。

不过我们找到了一种窍门：可以使用大型常规内存的服务器并将其视为缓冲空间。我们最终在一台具有 500GB RAM、1TB SSD 交换空间和 64GB 受保护内存的机器上运行，它们更便宜且更广泛可用。性能稳定在约 130 mgasps，这足够好。

尽管这种方法确实有一些限制，但我们发现这是在 SGX 内部运行 Geth 的可行选择。

总结

在 SGX 内部运行 Geth 完全是可能的，但这是一个资源密集且耗时的过程。它需要大量内存，启动时间约为 3 小时，并且状态容易丢失。

虽然将数据库存储在内存中并使用加密交换空间提供了良好的性能，但仍可能会受到某些类型的信息泄漏的影响。另一方面，在 SGX 内部使用加密文件系统可能是直接且资源占用较低的方法，但它可能会引入性能问题，而且信息泄漏风险更难避免。

最终，仔细评估你特定应用程序的需求并选择最适合满足这些需求的解决方案非常重要。

通过发布我们的代码和经验，我们希望提供一个参考实现，并刺激更广泛的探索和合作！

未来工作

• 可重复构建（使对在 SGX 中运行的代码的信任成为可能）
• 向 Gramine 添加 flock 系统调用
• 探索 Gramine 加密文件系统挂载的缓慢问题
• 探索可能的信息泄漏及其影响
• 在链上验证证明

感谢

特别感谢 Mateusz Morusiewicz 和 Tomasz K. Stańczak 的支持和创造力，他们帮助实现这一目标并解决了一些问题，也感谢 Alejo Salles、Jonathan Passerat-Palmbach 和 Robert Miller 在草稿审阅方面的帮助。

参考文献

• 你可以在 github.com/flashbots/geth-sgx-gramine 找到我们在 SGX 内部运行 Geth 的代码。
• 加入我们的论坛，在这里讨论和合作：https://collective.flashbots.net/t/running-geth-within-sgx-our-experience-learnings-and-code-flashbots/938
• 另请参阅本系列的第二篇文章：在 SGX 内部构建区块

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