在SGX内的区块构建

我们很高兴地宣布，Flashbots 已成功在 SGX 隔离区内运行一个区块构建器，SGX 是由 Intel 开发的受信执行环境 (TEE)。SGX 区块构建器现已在以太坊 Sepolia 测试网启动，并将很快在主网上线！

我们之前在 SGX 内运行 Geth 的相关工作 展示了这一方法的技术可行性。现在，我们已朝着在加密隔离区内进行区块构建迈出了下一步，并希望分享我们的关键学习和挑战，以及运行 SGX 内部区块构建器的所有 代码与工具。

在加密隔离区内实施区块构建使我们更接近于实现交易机密性和去中心化的区块构建角色。

在隔离区内运行区块构建算法确保区块构建者及其他基础设施提供者无法看到用户交易的内容，并能够在这些交易上运行可验证的区块构建算法，从而在不损害用户隐私的情况下确保经济高效的区块。

展望未来，SGX 内部的构建者可以制作可证明有效并真实报告其投标规模的区块，可能消除了 mev-boost 中继的需求。

此外，这朝着通过允许交易在私密但对所有在隔离区内的区块构建者可访问的情况下，抑制独占订单流的风险迈出了重要一步。

我们的 Sepolia SGX 构建器

Flashbots 在 Sepolia 的 SGX 构建器使用公钥 0x9817fc7d....，其区块附加数据为 Illuminate Dmocrtz Dstrib Prtct。

• 可通过 中继数据 API 查询已交付的区块
• 示例区块在这里： sepolia.etherscan.io/block/3013275

代码与工具

运行 SGX 构建器所需的代码和工具可以在此库中找到：github.com/flashbots/geth-sgx-gramine。

• 详见 README中的构建器快速入门
• 以及 拉取请求 中所有更改的概述

硬件

我们使用 Azure DCsv3 系列 的硬件，具体如下：

• 对于 Sepolia: Standard_DC2s_v3 实例，配有 2 核心和 16GB 内存 + 64GB SSD 交换文件。
• 对于主网: Standard_DC48s_v3 实例，配有 48 核心，384GB 内存 + 2TB Premium SSD 硬盘作为交换空间。

代码细节

SGX 构建器发布包含对原始 Geth-SGX 代码库的几项改进和补充：

• 完全可用的 Flashbots 区块构建器（分支 capella-test）
• 支持 远程证明，允许任何人验证 SGX 证明：
  • 在启动时创建一个远程证明 TLS (RA-TLS) 证书，嵌入 SGX 证明报告。
  • 有关 RA-TLS 的更多信息，请参见 这里 和 这里，以及用于将其添加到构建器的 补丁 代码库。
  • RA-TLS 被多个 SGX 项目使用，包括 Gramine、Open Enclave 和 Inclavare Containers。
• 通过对 Gramine 1.4 的更新，支持 EDMM（隔离区动态内存管理）。EDMM 不再需要在启动时保留和写入所有内存，这有可能显著加快启动过程。
• 指南 用于证明 SGX 构建器的证书
• 可重现的构建器 Docker 镜像，重建构建器 Docker 镜像时得出可重现的 MRENCLAVE 值。

挑战

Geth 状态大小

截至发稿时，geth 数据库需要大约 1TB 的存储空间。

• 数据库需要加密并在每次启动时复制到隔离区。考虑到完整的主网 geth 数据库约有一 terabyte，启动过程大约需要 4.5 小时。
• 这也意味着重现错误所需的时间较长。
• Gramine 在隔离区中遇到 1TB 状态崩溃（我们已提交了 错误报告）
• 一个有希望的方向是这个 geth PBSS 补丁（自动修剪存储），可能将状态大小减少到约 150GB（欲了解更多细节参见 这篇文章）
• 编辑：我们通过将古老数据库保存在隔离区外使其工作（见 这里），将内部所需状态减半（约 ~500GB）。

合并性能和额外延迟

• SGX 构建器当前性能约为 ~150 mgasps，相当于非 SGX 构建器性能的一半。
  • mgasps 意味着“每秒百万Gas”，在每次处理新块时测量，提供一个良好的性能指标。
  • 实际上，这意味着 SGX 构建器在运行相同的区块构建算法时只能进行非 SGX 构建器一半的模拟次数。
• 这种性能下降的一个可能原因是 Go 语言处理系统调用的方式。Go 语言直接调用内核，而不是使用 libc 系统调用接口。这导致在 SGX 隔离区内运行时产生额外的执行开销。通过使用 gccgo 构建 geth 可能会带来改进。

允许公众访问构建器和防止垃圾信息

• 公众用户希望直接连接到隔离区内部的代码（通过 TLS），以便验证系统确实在 SGX 内运行，并且代码确实是他们期望的。
• 这还意味着请求内容无法被外部基础设施的任何部分检查，这将简化 TLS 终止、速率限制、垃圾信息防止、负载平衡和声誉管理。
• 在当前的单 SGX 实例设置中，单个构建器实例将接收所有用户连接，终止 SSL 连接，并处理请求。然而，构建器希望专注于构建，而不是终止 TLS 连接或处理垃圾信息。
• 一个仍然是无权限的临时解决方案可能是应用重度网络基于速率限制。
• 为了实现可扩展的 SGX 基础设施，我们将公开探索可处理外部请求的端到端 SGX 设计架构，并通过预模拟来防止垃圾信息。

可重现构建

• 我们实现了构建器应用程序本身的可重现 SGX 构建，但 Gramine 基础以及某些系统库尚未可重现，上游版本需要信任。我们正在与各团队合作，旨在实现端到端的可重现构建。
• 有关可重现 Gramine 构建的更多信息，请参见 这里 和 这里。

未来工作

• 在主网上运行 SGX 构建器（即将来临）。
• 允许用户直接向 SGX 构建器提交包。
• 探索可扩展的公共 SGX 基础设施设计，可能为 分布式构建设计铺平道路。
• 实现端到端可重现构建。
• 性能改进，特别是在系统启动和区块合并方面。
• 探索隐秘信道攻击的影响和缓解（通过资源使用模式泄露私人信息）以及侧信道攻击和其他漏洞。
• 实现双向 TLS 和双向证明，允许多个 SGX 隔离区通过互相验证其 SGX 证明来建立受信连接。
• 进一步实现 SGX 化技术栈的其他部分，以实现端到端交易机密性（即 mev-boost 中继、搜索器堆栈、包中继等）。
• 探索除 SGX 之外的其他 TEE 系统（即 AMD SEV、ARM、Nvidia H100+ 协处理器等）。

感谢

感谢 konVera 在此项目上的出色合作，以及感谢 Mateusz Morusiewicz 和 Tomasz K. Stańczak 为实现这些目标所做的工作。 特别感谢 Kailin Rutherford、Robert Annessi、Alexo、Bert 和 Tina Z 对此文章草稿的审阅。

参考

• 你可以在 github.com/flashbots/geth-sgx-gramine 找到我们运行 SGX 内部构建器的代码和工具。
• 还可以查看 SGX 系列的第一篇文章：SGX 内运行 Geth。
• 关于分布式区块构建（拓展构建器设计空间）由 Alex Stokes 负责。
• 欢迎你在论坛中讨论和合作！ collective.flashbots.net/t/block-building-inside-sgx/1373

更新

2023-03-14：我们通过将古老数据库与 SGX 状态数据库分离，成功运行主网 SGX 构建器。

• 更多细节请见 拉取请求： geth-sgx-gramine#10
• 首个区块已经通过 SGX 构建器在主网上线：https://etherscan.io/block/16813125

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