大幅减少带宽消耗的PeerDAS - 网络

作者： pop

概要： 这个提案将 PeerDAS 的带宽消耗降低了 56.2%。

• 由于这个提案是对 PeerDAS 的改进，需要熟悉 PeerDAS (PeerDAS 介绍)。
• 主题观察 (主题观察提议) 是这个设计的基础，所以如果先阅读它会很有帮助。

目前，GossipSub 对 PeerDAS 的带宽消耗施加了一个放大因子，因为不止一个节点可以向你发送相同的列。 事实上，你只需要一个副本，所以这种放大浪费了你的带宽。

之前我们实现了 IDONTWANT，它可以减少你将收到的副本数量，但它不能保证确切的数量。

这个提案使节点能够只接收他们采样的大部分列的一个副本。

当前带宽消耗

（为了简单起见，假设 DATA_COLUMN_SIDECAR_SUBNET_COUNT 和 NUMBER_OF_CUSTODY_GROUPS 等于 NUMBER_OF_COLUMNS）

设 S 为 SAMPLES_PER_SLOT, C 为列的大小，D 为 GossipSub 的放大因子（又名 mesh degree）。

节点需要订阅并采样 S 列，因此每个节点每个 slot 必须消耗大约 D*S*C 字节的带宽。

新设计

之前，我们让每个节点订阅 S 个 GossipSub 主题。 现在，我们订阅的主题比这少。 我们让每个节点订阅 K=2 个主题，这低于 S。节点仍然会在这些 K 个主题中接收或转发 D 个副本，但他们将只接收一个副本，并且不转发剩余的 S-K 个主题的任何副本。

我们仍然需要订阅 K 个主题的原因是，我们需要为主题提供主干，这是 主题观察（又名主题的稳定性）所要求的。

K 个订阅的带宽消耗为 D*K*C 字节/每 slot。

\ slot-breakdown1589×485 41.2 KB

现在，剩下的问题是节点如何获取它需要的剩余的 S-K 列。

首先，你在 slot 的开始观察主题（显示为蓝线）。

之后，你的节点会在主题中有新消息时通知你。 橙色线显示了你的节点何时通知你。 请注意，节点 2 是第一个获取消息（列）并首先通知你的人。

由于节点 2 首先通知你，你使用超时 T (400 ms) 从节点 2 请求实际列。 超时后，如果你没有从节点 2 获取它，你可以从第二个通知你的节点（节点 4）请求它。 如果你仍然没有得到它，你会继续进行。 红线显示了你何时从每个节点请求列。 更远的线更浅，表示可能性较小。 连续的线相隔 400 毫秒，表示超时。

看起来超时会大大延迟列的接收，因为使用当前的 PeerDAS，你会在橙色线上立即获得列，这更快。 事实上，由于以下原因，情况并没有那么糟糕。

1. 它节省了大量带宽。 想象一下，你在每条橙色线上都获得一列的副本。 这看起来非常浪费。 通过这个提案，你只能在其中一条红线上获得一个副本。
2. 超时很少发生。 你不期望发生很多超时，原因如下。
   • 网络状况已经很好。 如果不是，你的节点怎么可能通知你它收到了消息？ 如果你可以通知我，你也可以发送列给我。 如果它不这样做，你可能会降低它的得分。
   • 你的节点可以提前发送拒绝，而无需等待超时。 例如，如果你的节点超载并且不想浪费带宽向你发送列，它可以只向你发送一个拒绝，你可以快速转移到另一个节点。

新的带宽消耗

• 由于订阅 K 个主题而产生的带宽消耗为 D*K*C 字节/每 slot。
• 由于观察和下载剩余的 S-K 列而产生的带宽消耗为 (S-K)*C 字节/每 slot。
• 由于将列发送到观察节点而产生的带宽消耗与上述相同，为 (S-K)*C 字节/每 slot。

总带宽消耗将为 (D*K+2*(S-K))*C 字节/每 slot。

使用规范中的当前赋值分配参数：D = 8，K = 2 和 S = 8。

• 当前 PeerDAS 的带宽消耗为 64*C。
• 新的带宽消耗为 28*C，降低了 56.2%。

我分配 K=2 的原因是，如果 有 8k 个节点, 列数为 128，每个主题中将至少有 100 个节点。

悲观地看，如果你认为 K=2 不足以使主题足够稳定，我们可以增加到 K=4，带宽消耗将为 40*C，仍然降低了 37.5%。

与 IDONTWANT 的比较

你可以注意到，前几节中的分析假设在订阅主题时，你将精确地接收或转发 D 个消息副本。

使用 IDONTWANT 并非如此，因为它可以通过在你节点向你发送副本之前向你的节点发送 IDONTWANT 来减少你将接收的副本数量。

仍然有一种极端情况，IDONTWANT 根本无法帮助减少副本数量。 想象一下，你的所有节点都同时向你发送消息（橙色线非常接近），因此你没有机会及时向它们发送 IDONTWANT。 因此，在这种情况下，你仍然接收与之前相同数量的副本。 而在这个提案中，保证你只会收到一个副本。

但是，我们可以将这个提案与 IDONTWANT 结合起来，以获得更好的协议。 由于节点仍然订阅 K 个主题。 IDONTWANT 可以在那里减少大量的带宽消耗。

与 Peer Sampling 的比较

Peer sampling 是一个过程，在这个过程中，在所有列都通过网络传播之后，你从应该拥有它的节点请求一列。 如果你取回该列，则表示该列可用。 如果没有，你可以请求另一个节点或确定该列不可用。

你可以看到你总是请求一个列，无论如何，这与这个提案不同。 在这个提案中，只有当你的节点通知你它有列时，你才会请求一个列。 因此，peer sampling 和这个提案从根本上是不同的。

另一个区别是，在 peer sampling 中，你不确定何时请求一个列。 换句话说，你不知道列的传播何时完成，以便你可以开始请求该列。 你可以做的是设置一个确切的时间戳，你将假设传播已经完成并开始请求。 这有时会浪费你一些时间，因为传播在时间戳之前很久就完成了。 在这个提案中，你没有这个问题，因为你会在可以请求时收到通知。

• 以太坊中的带宽可用性：区域差异和网络影响

• 原文链接： ethresear.ch/t/peerdas-w...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～