如何拆除 Relay - 提高构建者与提议者之间的安全性

MEV-Boost，目前在以太坊中用于 MEV 提取的侧车协议，严重依赖于被称为Relays（中转）的中心化参与者。

我们提出了一种替代架构，该架构允许构建者和提议者之间进行直接的、加密隐私的通信。它基于一种新的非交互式 "静默" 门限加密形式，可以使用验证者的现有 BLS 密钥对。

本质上，我们借助于证明委员会来实现隐私和数据可用性，通过对该时段的部分验证者进行门限加密块提案。他们的证明形成了解密密钥；一旦达到所期望的门限定义，区块就可以被解密。

我们的构造解决了构建者和提议者之间的隐私问题，但单独并不保证区块有效性。它可以与其他机制相结合，完全复制Relays提供的功能——包括隐私和区块有效性。例如，像可信执行环境（TEE）证明或零知识（ZK）证明等证明方案，或者加密经济机制用于对构造者进行担保。

通过消除Relays提供构建者隐私和确保区块有效性的需要，我们旨在减少延迟并改善以太坊的去中心化和抗审查性。

MEV-Boost 和Relays的角色

MEV-Boost 是一个侧车协议，它在块构建者和提议者之间进行中介。Relays的主要角色是提供两个保证：

1. 构建者隐私：Relays确保提议者无法看到区块内容并窃取构建者找到的 MEV。
2. 提议者安全：Relays保证构建者要向提议者支付构建者出价中承诺的金额，并且区块是有效的（例如，所有交易支付内在Gas费）。

然而，对Relays的依赖引入了显著的中心化。大约 90% 的以太坊区块是通过少数Relays交付的。这带来了一些风险：

• 中心化：构建者可以通过与Relays共同托管来提高延迟效率，而不是反映提议者的地理分布。这直接削弱了我们否则可能从大规模、全球分布的验证者集中获得的地理去中心化和抗审查能力。
• 收入：高效Relays的平均端到端块处理延迟约为 5-20 毫秒。然后，提议者与构建者之间存在通信延迟。跳过Relays将减少延迟，降低跨域执行风险（例如 CEX/DEX），并最终增加提议者的 MEV 奖励。

TEE-Boost

替代Relays的主要提案之一是“TEE-Boost”，它依赖于 TEE（可信执行环境）。请注意，TEE 对我们的方案并不是必需的；使用 TEE-Boost 作为我们旨在解决问题的教学示例是有帮助的。

具体而言，TEE-Boost 让构建者使用 TEE 创建证明，向提议者展示他们的出价的诚实性和区块的有效性，而不向提议者透露实际的区块内容。提议者可以在商品硬件上检查这些证明，而无需自己运行 TEE。

然而，TEE-Boost 存在 数据可用性问题：构建者只与提议者分享 TEE 证明和区块头，而不是实际的区块内容，并且可能选择在提议者签署头部后不释放区块内容（例如，如果市场条件变得不利）。解决此 DA 问题的建议方法如下：

1. TEE-托管：TEE-托管在提议者签署区块之前从构建者处获取区块，并在其看到签署的区块头后释放。
2. 数据可用性层：构建者将加密的块载荷发布到数据可用性（DA）层。

这两种方法都存在缺点。TEE-托管解决方案复制了与现有Relays类似的中心化延迟动态。[2] 使用外部 DA 层引入了额外的协议假设，并承担了该外部协议的延迟动态（这些可能也是不利的）。

门限密码学以实现构建者隐私

我们提出了一种优雅的解决方案来解决 TEE-Boost 的 DA 问题：向验证委员会进行门限加密。具体而言，构建者将区块门限加密到该时段的指定部分验证委员会。一旦收集到足够的证明，区块变得可解密并可用。

核心启用技术是 静默门限加密。这种密码学技术允许执行门限加密，而无需交互式分布式密钥生成（DKG）设置阶段，过去的构造要求这样的设置。相反，联合公钥是从验证者已存在的 BLS 公钥以及一些“提示”（后面会讨论）可确定性计算出的。

这实现了构建者与验证者之间直接的单跳通信，并确保了加密隐私。验证者并不需要自己运行 TEE 或管理任何新的密钥材料。

机制：

1. 构建者构建一个区块并将其加密到验证委员会。
2. 构建者构造 TEE 证明，向验证委员会展示三件事：出价是诚实的，区块是有效的，并且加密正确。
3. 构建者将门限加密的区块和 TEE 证明（包括出价值）传达给提议者。[3]
4. 提议者签署获胜构建者的加密区块，并将此提议传播给验证者集合。
5. 一旦指定的部分（例如 $ \frac{n}{2} $ 或 $ \frac{2n}{3}$ ) 的 $n$-验证委员会对区块进行了证明，它就被解密。
6. 解密后，区块正常进入终结(finalization)。

考虑要素

性能

静默门限加密的性能特性相当良好。这里 $n$ 是我们希望支持的委员会的最大规模，而 $t$ 是解密的门限。

加密和部分解密都是常数时间。使用一个简单实现，加密大约花费 $<7$ 毫秒——这可以并行化。部分解密花费 $<1$ 毫秒。

密文大小是一个常数加法因子，比明文（对于任何 $n$ 和 $t$ ）大 768 字节。

部分解密的聚合（即解密）取决于委员会的规模。当 $n=1024$ 时，简单实现的时间为 $<200$ 毫秒。我们预计，当 $n=128$ （每个时段的验证委员会的规模）时，这个时间会减少 10 倍，而且实现可以进一步优化。

重要的是，加密时间是与Relays延迟进行比较的关键性能指标。这是构建者在区块生产的“关键路径”中必须计算的内容。它低于现有Relays的区块处理延迟，并避免了多跳通信。

数据发布

静默门限加密并不是完全免费的。它确实需要一种形式的公共参考字符串：

$(g, g^\tau, g^{\tau^2}, \dots, g^{\tau^{n-t}})$ ，类似于用于 KZG 多项式承诺方案的内容。

此外，每个具有 BLS 公钥形式的验证者 $g^\mathsf{sk}$

发布一组我们称之为“提示”的群元素：$(g^{\mathsf{sk}\cdot \tau}, \dots, g^{\mathsf{sk}\cdot \tau^{n-t}})$ 。这些提示仅在聚合公钥和解密密文时需要。加密仅使用大小常数的聚合公钥。

撰写此文时，大约有 100 万验证者。如果我们设置 $n=128$ 和 $t=n/2$ ，则每个验证者需要发布约 3 KB 的提示。因此，存储所有验证者的提示需要 3 GB。

这一要求在MaxEB激活后可能会大幅减少，MaxEB 允许控制 >32 ETH 的验证者在同一密钥对下持有更大的余额（而不是将其分散到多个 32 ETH 存款中）。验证者集的减少程度尚有争议。我们似乎可能能降到 ~1GB。

最后，取决于以太坊共识架构的未来变化（例如进一步减少验证者集大小，或替代终结流水线），所需存储的提示大小可能进一步减少。

活跃性

以太坊希望在不利的网络条件下仍然保持活跃。该方案的一个问题是，可能会出现因为提交的委员会的指定部分离线而无法解密区域块的情况。

一种解决方案是允许构建者决定解密的可接受份额（𝑡）。隐私（拆分和 MEV 窃取的可能性）和委员会门限在线的可能性之间存在权衡。对构建者而言，让他们的区块被包含在内，而不是被拆分出去，才是收入最大化，因此他们应该确定一个优化的门限设置。[4]

此外，使用这一加密方案应为自愿选择。在不利的网络条件下，在没有可接受大小委员会持续可用的情况下，提议者和构建者可以选择回归使用Relays、自行构建，或者根据不利环境性质使用其他更佳机制。

不可用的区块

另一种情况是委员会可能在线，但构建者可能会创造一种情况，使得区块在解密后无法被解密或无效（例如通过欺诈证明）。

从协议的角度来看，将这些区块拆分出去是可以的。更广泛的验证者集根本无法对此些区块或任何引用它们的区块进行证明。这种错误的最佳处理方法可能是使共识客户端能够意识到这种可能性，并能够优雅地失败。确切的处理方法需要进一步研究。

市场结构

获胜的构建者在达到门限之前知道区块的内容，这可能会在后续时段创造不公平的优势。然而，证明委员会应在下一个时段结束之前采取行动，而区块价值的多数位于时段结束时，因此这种优势的影响应该是尽可能地小。

纯粹的加密证明

从长远来看，可能可以用零知识（ZK）证明替代 TEE 证明。目前，ZK 证明速度太慢，但加密学、软件和专用硬件（ASIC）领域的进展可能最终使 ZK 证明生成在必要的延迟约束内成为可行的。值得注意的是，伴随区块的 ZK 证明已经是 以太坊长期路线图 的核心部分。

采用

考虑到当前的验证者集规模和增长率，该方案可能不值得在 L1 上发布的数据量。然而，以太坊已经计划通过 MaxEB 大幅减少验证者集的数量。

最佳方案可能是在 MaxEB 之前或之后进行升级，在此过程中让共识客户端意识到加密区块语义的可能性，并鼓励验证者发布提示。例如，在 MaxEB 之后，可以要求新进入的验证者发布提示，并为老验证者提供升级的激励。

一旦足够比例的验证者集采用该机制以使委员会规模达到足够（即，同时满足可接受隐私和解密的可能性），构建者将开始使用该机制。

如果我们的方案确实相对于多跳中继具有良好的延迟，市场应该会在无需协议强制使用或具体参数化的情况下采纳它。

理由

Relays是以太坊最重要的中心化来源之一，创造了寻租的机会，并扭曲了协议的地理去中心化。

我们需要消除Relays，并认为这是一种相对优雅的方式来做到这一点。它需要在共识层进行更改，但对验证者不需要新的硬件或密钥材料。

缺点是，对共识层的复杂更改可能是一个机制（如建议的自愿选择）市场可能会采用，也可能不会使用。然而，对 MEV 流水线的许多潜在更改具有类似的采用和收益优化问题（例如，包含列表）。此外，可能还有其他未来用例依赖于验证者集具备门限加密基础设施。

致谢

感谢 Dan Robinson, Georgios Konstantopolous, Frankie, Shea Ketsdever, Quintus 和 Mike Neuder 的反馈和审核。

1 ↩ 从理论上讲，如果提议者也能获得 TEE，构建者可以将他们的块加密到由提议者运行的 TEE 上。提议者的 TEE 只有在签署该区块后才会解密它。然而，我们认为 TEE-Boost并未考虑这一设计，因为这将要求提议者（验证者）运行 TEE。我们希望验证者能够在商品硬件上运行。

2 ↩ 如果提议者自己运行 TEE-托管作为其验证者节点的联合侧车，则可以避免延迟动态。然而，我们仍然不希望让验证者跑 TEE。

3 ↩ 对提议者带宽要求的影响需要研究。低带宽提议者可通过在请求块体之前验证证明，或者使用其他启发式过滤和智能下载技术来限制需求。这是一个待开放的问题，但似乎没有比正常的内存池闲聊垃圾邮件更难解决的困难。

4 ↩ 这里的具体声明是，构建者的区块被拆分出去是负的 EV（期望值），因为他们从中没有获得收入，并且在 unbundled 的情况下会非常负的 EV。如果给构建者选择 $t$ 在 $ [0,128]$ 的话，他们应该自然被激励选择 $t$ 足够高，从而极低风险够发生 unbundling，并高概率满足（至少 $t$ 与会成员在线）。即使在正常网络条件下，某些区块可能会被拆分出去，但我们会注意到这已经发生在时序游戏中，链的活跃性仍然可以接受。

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