网络匿名化内存池

这篇文章是 Flashbots 研究系列的一部分，探讨了去中心化区块构建如何将以太坊的扩展和隐私路线图与现实世界的执行联系起来。

概要： 这篇文章介绍了 Flashnet，一种新的匿名广播协议，比现有的替代方案具有更低的延迟。我们计划部署 Flashnet，既可以 (1) 作为面向用户的审查抵抗和匿名工具，补充链上隐私解决方案和审查抵抗机制，如 FOCIL；又可以 (2) 作为连接区块构建流程中参与者的一种手段，使 BuilderNet 更接近于无需许可和 SUAVE 愿景。Flashnet 是分布式区块构建的事件视界——信号通过，发送者消失。

介绍

隐私是在以太坊生态系统中团结不同选区的一些属性之一。密码朋克关心它，将其视为人身安全、自主权和审查抵抗的问题。产品构建者和协议设计者关心它，因为信息不对称塑造了市场结构。在这两种情况下，隐私都不是表面上的功能，它决定了谁可以在什么条件下、承担什么风险参与系统。有鉴于此，我们很高兴推出 Flashnet，一种新的低延迟匿名广播协议。

以太坊在隐私方面取得了有意义的进展。PSE 的以太坊隐私路线图 将问题很好地分为私有读取（查询状态）和私有写入（提交交易）。私有读取正在通过 基于 TEE 的 RPC 在短期内和长期内的密码学技术 加以解决。私有写入已经通过隐身地址和屏蔽池（如 Railgun 和 Privacy Pools）取得了进展，这大大降低了链上可链接性。

虽然“读取”和“写入”是（正确地）将以太坊建模为数据库的术语，但区块构建将以太坊建模为分布式执行管道，该管道写入此数据库。隐私失败不仅发生在状态访问中，而且发生在信息在执行期间如何通过此管道流动中。即使交易内容被隐藏，交易发送者的身份也可能不会被隐藏。简单地使用像 Railgun 或 Privacy Pools 这样的混币器并不能阻止攻击者跟踪你的元数据（例如，IP）、连接你的帐户以及跟踪你的身份和位置。它也无法阻止基于此信息的审查或抢先交易。缺失的属性是网络匿名性。

Flashnet 提供了完全相同的属性。该协议既可以作为用于交易提交和账户抽象 mempool 的面向用户的匿名和审查抵抗工具，也可以作为 无需许可的区块构建的协调原语。

区块构建中的匿名性

从 orderflow.art 看到的以太坊执行管道

三年前，我们宣布了 SUAVE，我们对去中心化区块构建供应链的愿景，该供应链解耦了区块构建角色。当时，区块构建不仅是中心化的，而且几乎没有方法可以向区块构建者隐藏交易内容，也没有不影响所需延迟的匿名解决方案。在对隐私原语进行了大量研究（SGX、MPC、FHE、TDX）之后，我们推出了 BuilderNet，引入了新的隐私和可验证性保证，并迈出了实现我们愿景的第一步。

添加这些保证不仅仅是因为它们与密码朋克的理想相符而具有吸引力。正如我们在最近的文章 去中心化构建：干什么 中解释的那样，我们将强大的隐私工具视为 DeFi 成功的必要条件。DeFi 交易的执行路径通常涉及许多参与者——订单流拍卖、求解器、中继器、构建者、验证者——执行质量取决于它们之间的互动。随着我们开发出在不冒滥用风险的情况下共享敏感信息的能力，区块链执行管道将能够纳入更多的交易对手、更多的策略和更多的信息，从而有利于去中心化和执行质量。

到目前为止，我们只迈出了第一步。即使基础设施在 TEE 中运行，运营商仍然能够学习元数据， 从而为 选择性审查 和 对抗性 MEV 策略 打开了攻击面。现有的匿名解决方案（如 TOR 和 Nym）要求用户在弱匿名或高延迟之间做出选择。同样，FOCIL 承诺增加审查抵抗，但代价是更高的延迟和需要使用公共 mempool，这会导致抢先交易和其他不良形式的 MEV。这些权衡在很多用例中可能是不切实际的。

对于简单的转账，高延迟仅仅意味着相对于未受保护的设计而言，糟糕的用户体验。这听起来可能没什么大不了的，但更多的使用意味着对于最需要它的用户来说，匿名性更强。对于 DeFi 和其他涉及有争议状态的用例，结果很大程度上取决于其他交易（例如，同一 DEX 上的交换）以及中心化交易所上的毫秒级价格变动。对于这些用例，延迟可能会转化为金钱损失或完全阻止参与。 随着我们降低延迟开销，相同的匿名广播原语既可以保护 Railgun 用户免受基于元数据的去匿名化攻击，也可以防止区块构建者或中介机构根据网络身份过滤或不利地对待参与者，并将区块传递给验证者。

今天，BuilderNet 区块正在由 Flashbots、beaverbuild 和 Nethermind 构建，因为我们能够验证这些节点在安全环境中运行适当的隐私保护软件。我们下一个计划的架构将区块构建模块化并分布在更大的一组专业参与者中。整合 Flashnet 是实现这一目标的一个步骤——这是让任何人运行节点并将 BuilderNet 扩展到声誉和信任限制之外的关键。

匿名性 vs. 延迟 vs. 带宽

在构建匿名广播通道时，三个指标至关重要：匿名性、延迟和带宽。

匿名性衡量的是外部（网络级）观察者辨别匿名广播系统发布的任何一条消息的发送者的难度。在实践中，这通常通过匿名集的大小来量化：给定消息的合理发送者的数量。

延迟衡量的是消息传递所需的时间，如上所述，我们希望延迟尽可能低。

带宽衡量的是系统需要发送和处理多少数据。即使很少有用户发送有意义的消息，我们也需要许多用户来提供“掩盖流量”，从而为每个人提供良好的匿名性。因此，系统的带宽开销不仅包括实际发送的消息，还包括匿名性所需的掩盖流量的数量。

在理想的世界中，我们希望匿名性最大化，而延迟和带宽开销最小化。然而，在现实中，没有免费的午餐，通常必须在至少一个指标上付出代价。毕竟，没有三难困境的区块链帖子算什么？

这里值得简要回顾几个已建立的蓝图：

洋葱路由， TOR 网络著名地采用了它，在带宽开销方面非常高效，并允许每个客户端异步决定何时发送他们的消息。在实践中，它还可以实现低延迟，但代价是在对抗性网络级观察者面前的弱匿名性。

Mix-Nets，如 Nym，实现了更强的匿名性，可以抵御全球被动攻击者。它们依赖于掩盖流量，以及消息的批处理和重新排序，这会引入延迟。与低延迟网络相比，结果是增加了端到端延迟和更高的带宽开销。

DC-Nets（“餐饮密码学家”网络）不同于基于中继的设计，如 TOR 和 Nym。参与者不是通过网络上的几台机器路由消息，而是同时参与共享计算，该计算显示一批消息，而不会将发送者链接到消息。DC-Nets 可以在同步设置中提供强大的发送者匿名性，并具有适度的延迟，但通常以更高的带宽和计算开销为代价。

由于匿名性来自提供的掩盖流量，因此 DC-nets 松散地类似于工作量证明或权益证明协议，其中带宽是与安全性密切相关的资源。

一般来说，没有一种解决方案优于所有其他解决方案，不同的用例可能需要不同级别的匿名性。在这篇文章中，我们专注于以太坊执行管道的网络匿名化，其中网络级别的最大发送者匿名性是主要目标。因此，我们接受实现此级别的匿名性可能需要在带宽和/或延迟方面付出代价。

TEE 的救援

最近一种名为 ZipNet 的匿名通信协议做出了一个简单但有力的观察。在设计匿名通信协议时，许多计算和带宽效率低下源于需要确保活跃性，而不是匿名性。利用这一观察，ZipNet 在 TEE 的帮助下确保活跃性，并通过经典的密码学手段确保匿名性。如果 TEE 被破坏，系统可能会变得无响应，但匿名性不依赖于 TEE 的安全性。

在 ZipNet 中，客户端通过任何信任服务器组以同步的回合发送消息。ZipNet 在延迟方面非常高效，与不匿名发送消息相比，具有适度的带宽开销，同时提供强大的匿名性保证。不幸的是，ZipNet 有一个主要弱点：只要一台服务器离线，它就会变得无响应。

Flashnet

我们提出了一种新的匿名广播方法，与 ZipNet 一样，它使用 TEE 来确保活跃性，但依赖于经典的密码学手段来确保匿名性。然而，与 ZipNet 相比，我们的系统即使在某些服务器离线时也能保持活跃。我们提供最强级别的匿名性，从某种意义上说，没有广播的消息可以归因于特定的客户端，并且以适度的带宽开销实现低延迟。从安全角度来看，我们考虑的是一种可以监视所有网络流量的对手，甚至可以控制匿名通信系统中一小部分参与者。

从高层次上看，我们的系统由三个角色组成：客户端、服务器和领导者。

客户端是那些想要匿名发送消息的人。他们可能是恶意的，并试图破坏系统。我们假设每个客户端都在本地运行 TEE。如果客户端没有 TEE，他们可以委托给有 TEE 的人，但这会带来信任假设方面的代价，因为现在他们需要依赖 TEE 安全性来实现匿名性，而不仅仅是活跃性。可以放宽此假设，改为客户端上的非勾结假设，但这会增加协议的复杂性，因此我们的第一个迭代版本假设客户端端有 TEE。

服务器形成一组机器，我们假设其中至少一半是诚实的。这些机器接收来自客户端的加密流量。服务器解密传入的流量，将其转换为最终输出的份额，并将这些份额转发给领导者。

领导者接收来自每个服务器的份额，并生成最终输出，然后将其传播到公共 mempool。即使某些服务器无响应或完全恶意，只要有足够多的服务器发送消息，领导者也可以可验证地生成正确的输出。

Flashnet 流的面向用户的示例。

更详细地说，高级协议的工作原理如下：

1. 每个客户端在本地准备一个空数组数据结构，并将他们的消息放置在该数组中的某个随机位置。
2. 然后，客户端在服务器之间秘密共享他们的数组。
3. 每个服务器接收来自每个客户端的份额，并且可以在本地将这些份额相加，从而导致各个向量之和的份额。然后，每个服务器可以将他们的份额转发给领导者，领导者可以使用所有份额来重建最终输出。
4. 这里的关键观察结果是，消息存储在与它们身份分离的数组中的随机位置，从而确保匿名性。我们注意到，客户端消息可能会在同一插槽中冲突，但我们的协议通过使用稍微复杂的数据结构而不是普通数组来解决这个问题。

轻量级的密码学检查可以保证服务器的诚实，而客户端的 TEE 可以确保客户端正确地准备他们的数组并诚实地进行秘密共享。如果没有 TEE 强制执行格式良好的输入，恶意客户端可能会错误地用随机值填充其数组中的所有位置，从而导致汇总向量汇总为垃圾。这将破坏活跃性，但不会破坏匿名性。在这个简短的概述中，不同的诚实消息可能会意外地最终出现在同一个数组单元中。为简洁起见，我们省略了如何解决这个问题的技术细节，将在未来更技术性的博客文章中介绍我们的协议。

为了保护添加步骤免受恶意服务器的攻击，每个客户端都使用可加性同态向量承诺来验证其秘密共享——即，每个客户端都向其数组发送承诺，从而允许服务器计算对所有客户端数组之和的承诺，而无需学习单个输入。承诺方案的绑定属性确保没有服务器可以发布除其应发布的诚实份额之外的任何内容。

在我们的 去中心化区块构建阶段 中，Flashnet 完全适合 阶段 2，分布式构建。在这个阶段，计算分布在专门的参与者（如模拟器、搜索者、聚合器）之间，但最终的区块选择仍然是显式的和中心化的。我们希望 BuilderNet 的设计能够发展到更有效地整合像 Flashnet 这样的机制，并且 Flashnet 的变体最终可以直接整合到像 FOCIL 这样的 MCP 式设计中，但我们很高兴今天可以在没有重大协议更改的情况下完成部署。

结论

Flashnet 是隐私、扩展和去中心化如何在区块构建层融合的一个例子。通过将区块生产视为分布式协调问题，而不是整体的构建者或协议切换，我们可以提高执行质量、降低审查风险并保留以太坊的安全模型。 BuilderNet 和通往 SUAVE 的更广泛的道路不是抽象概念。它们是一个正在生产中的研发沙箱，以太坊可以在真实的对抗和经济条件下探索这些权衡，从而补充 L1 和 L2 协议工作，而不是与其竞争。这篇文章是更广泛的努力的一部分，旨在使该协调层清晰易懂，并邀请社区帮助塑造它。

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