MEV-Boost是当前以太坊中提取MEV的侧车协议，严重依赖于称为中继的中心化参与者。我们提出了一种替代架构，允许构建者和提议者之间进行直接的、密码学上私密的通信。这种架构基于一种新颖的非交互式“静默”门限加密形式，可以使用验证者现有的BLS密钥对。

本质上，我们通过门限加密区块提议，将其发送给一部分参与者，从而借助证明委员会实现隐私和数据可用性。他们的证明形成解密密钥；一旦达到所需的门限，区块就可以被解密。

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

通过消除对中继提供构建者隐私和确保区块有效性的需求，我们旨在减少延迟，提高以太坊的去中心化和抗审查能力。

MEV-Boost与中继的作用

MEV-Boost是一个侧车协议，充当区块构建者和提议者之间的中介。中继的主要作用是提供两个保障：

• 构建者隐私：中继确保提议者无法看到区块内容，也无法窃取构建者找到的MEV。
• 提议者安全：中继保证构建者按照其出价向提议者支付承诺的价值，并确保区块有效（例如，所有交易支付内在的Gas费用）。

然而，对中继的依赖引入了显著的中心化。大约90%的以太坊区块通过仅几家中继传递。这带来了几个风险：

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

TEE-Boost

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

具体来说，TEE-Boost要求构建者使用TEEs创建证明，向提议者展示其出价的诚实性和区块的有效性，而无需向提议者透露实际的区块内容。提议者可以在普通硬件上检查这些证明，而无需自己运行TEEs。

然而，TEE-Boost存在数据可用性问题：构建者只与提议者共享TEE证明和区块头，而不共享实际的区块内容[1]，并且可能选择在提议者签署头部后不释放区块内容（例如，如果市场条件发生不利变化）。解决这一数据可用性问题的建议方法包括：

TEE-保管：TEE-保管在提议者签署之前从构建者那里获取区块，并在看到签名头后释放该区块。

数据可用性层：构建者将加密的区块负载发布到数据可用性（DA）层。

这两种方法都有缺点。TEE-保管解决方案复制了类似于现有中继的中心化延迟动态[2]。如果使用外部DA层，则会引入额外的协议假设，并承受该外部协议的延迟动态（这些动态也可能不利）。

1. 从理论上讲，如果提议者也可以访问TEEs，构建者可以将其区块加密到提议者运行的TEE中。提议者的TEE只有在签署后才会解密该区块。然而，我们认为TEE-Boost没有考虑这种设计，因为这将要求提议者（验证者）运行TEEs。我们希望验证者能够在普通硬件上运行。↩

2. 如果提议者自己将TEE-保管作为与其验证者节点共同部署的侧车运行，则可以避免延迟动

态。然而，我们同样不希望使验证者运行TEEs。↩

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

我们提出了一个优雅的解决方案来应对TEE-Boost的数据可用性问题：对验证委员会进行门限加密。具体来说，构建者将区块门限加密到该时隙的指定比例的验证委员会。一旦收集到足够的认证，区块就可以解密并可用。

核心启用技术是无声门限加密。这种密码学技术允许进行门限加密，而无需先前构建所需的交互式分布式密钥生成（DKG）设置阶段。相反，联合公钥是根据验证者已有的BLS公钥和一些“提示”（稍后讨论）确定性计算得出的。

这实现了构建者和验证者之间的直接单跳通信，具有密码学隐私性。验证者不需要自己运行TEEs或管理任何新的密钥材料。

机制：

构建者构建一个区块并将其加密到验证委员会。

构建者构建一个TEE证明，向验证委员会证明三个方面：出价是诚实的，区块是有效的，并且加密是正确的。

构建者将门限加密的区块和TEE证明（包括出价值）传达给提议者。[3]

提议者对获胜构建者的加密区块进行签名，并将该提议传播给验证者集。

一旦指定比例（例如n/2或2n/3）的验证委员会对区块进行认证，它就会被解密。

解密后的区块将正常进行最终确认。

3. 对提议者带宽需求的影响需要进行研究。低带宽的提议者可以通过在请求区块主体之前验证证明，或采用其他启发式过滤和智能下载技术来限制需求。这是一个开放性问题，但解决起来似乎并不比正常的内存池传播垃圾邮件问题更困难。↩

注意事项

表现

无声门限加密的性能特征相当有利。在这里，n是我们希望支持的委员会的最大规模，t是解密的门限。

加密和部分解密的时间都是常量时间。使用简单实现，加密耗时小于7毫秒，并且可以并行化。部分解密耗时小于1毫秒。

密文大小比明文大768字节，这是一个常量附加因素（对于任何n和t）。

部分解密的聚合（即解密）取决于委员会的大小。当n=1024时，简单实现的耗时小于200毫秒。我们预计，当n=128（每个时隙的认证委员会的大小）时，这一时间将减少10倍，并且实现可以进一步优化。

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

数据发布

无声门限加密并不是完全免费的。它确实需要一个共同的参考字符串，形式为：(g, gτ, gτ², …, gτⁿ⁻ᵗ)，类似于用于KZG多项式承诺方案的内容。

此外，每个具有形式为g⁽ˢᵏ⁾的BLS公钥的验证者发布一组我们称之为“提示”的群元素：(g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ)。这些提示仅在聚合公钥和解密密文时需要。加密只使用常量大小的聚合公钥。

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

随着MaxEB的激活，这一要求可能会显著降低，MaxEB允许控制超过32 ETH的验证者在同一密钥对下持有更大的余额（而不是将其分散到多个32 ETH的存款中）。将实现的验证者集的减少还有待讨论。我们可能会降至约1GB。

最后，根据以太坊共识架构的未来变化（例如，验证者集规模的进一步减少或替代最终性流水线），必须存储的提示大小可能会进一步减少。

活力

以太坊希望在不利网络条件下仍然保持在线。该方案的一个问题是，由于指定比例的委员会处于离线状态，可能会出现无法解密的区块。

一个解决方案是允许构建者决定可接受的委员会比例(t)用于解密。隐私（解包和MEV窃取的可能性）与委员会阈值在线的可能性之间存在权衡。对构建者而言，使他们的区块被包含在链中，而不是被分叉，是最大化收入的，所以他们应该找到一个优化的阈值设置。[4]

此外，使用该加密方案应为自愿选择。在不利网络条件下，如果没有任何可接受规模的委员会能够持续在线，提案者和构建者可以回退到使用中继、自建或根据不利环境的性质选择的其他机制。

具体而言，构建者的区块被分叉出去的期望价值是负的（他们从中没有收入），而被解包的期望价值是非常负的。如果让构建者选择t在[0, 128]之间，他们应该自然而然地激励选择一个足够高的t，以降低解包的风险并提高被满足的概率（至少t名委员会成员在线）。在正常网络条件下，一些区块可能会被分叉出去，但我们注意到这已经发生在时间博弈中，而链的活跃性仍然是可接受的。↩

不可用的块

另外，委员会可能在线，但构建者可能能够制造一种情况，使得区块在解密时无法解密或无效（例如，使用欺诈性证明）。

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

市场结构

获胜的构建者在达到阈值之前知道区块的内容，这可能在后续时段中造成不公平的优势。然而，证明委员会应该在下一个时段结束之前采取行动，而区块价值的大部分集中在时段结束时，因此这种优势的影响应尽可能地减小。

纯粹的密码学证明

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

采用

根据当前的验证者集规模和增长率，这种方案可能不值得在L1上发布所需的数据量。然而，以太坊已经计划通过MaxEB显著减少验证者数量。

最好的方法可能是在MaxEB之前或之后进行升级，使共识客户端能够意识到加密区块语义的可能性，并鼓励验证者发布提示。例如，在MaxEB之后，可以要求新加入的验证者发布提示，而旧有的验证者可以获得升级的激励。

一旦足够比例的验证者集采用这一机制，构建者就会开始使用它，以确保有足够的委员会规模（即，兼顾隐私和解密的可能性）。

如果我们的方法在延迟方面确实优于多跳转发，市场应该会自发采用它，而无需协议强制使用或规定特定的参数化设置。

基本原理

中继是以太坊最重要的中心化来源之一，导致寻租机会并扭曲协议的地理去中心化。我们需要移除中继，并认为这是一个相对优雅的解决方案。它需要对共识层进行更改，但验证者无需提供新的硬件或密钥材料。

缺点是，这是对共识层的复杂更改，而这种机制（如果如建议的那样选择性采用）可能会被市场接受，也可能不会。然而，许多潜在的MEV管道变化也面临类似的采纳和收益最优化问题（例如，包括列表）。并且，未来可能会有其他用例依赖于验证者集拥有阈值加密基础设施。

声明：

1. 本文转载自[paradigm]，著作权归属原作者[Charlie NoyesGuru, Vamsi Policharla]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。