FullDAS：面向使用32MB及以上区块的大规模可扩展性 - 分片

本文提出了FullDAS，一种用于数据可用性抽样（DAS）的网络堆栈，旨在支持32MB及以上的大区块。FullDAS通过优化数据分散和抽样过程，包括liteDAS抽样协议、主题路由、改进的连接机制以及2D编码等技术，旨在实现快速、高效和稳健的数据可用性，从而解决当前网络堆栈在处理大数据块时遇到的瓶颈问题。

作者：Csaba Kiraly，与 Leonardo Bautista-Gomez 和 Dmitriy Ryajov 合作，来自 Codex.storage 研究团队。

注意：本文档描述了我们目前的想法，是与其他团队合作努力和多次讨论的结果。如果没有 @dankrad , @djrtwo , @fradamt , @AgeManning , @Nashatyrev , @matt , @pop , 和 @Echo 的贡献和想法，这是不可能实现的。

TL;DR

  • Danksharding 原计划使用 32MB 的区块，但我们当前的 networking stack 无法处理，成为了瓶颈。随着用于区块编码的 HW 加速 KZG 即将出现，我们的 networking stack 将不得不进行更大的扩展。
  • DAS 包含两个不同的概念：通过分散到托管来实现的 Data Availability（数据可用性），以及从托管处进行的 Sampling（抽样）。我们可以利用这种区别，设计高效的分散和高效的抽样协议。
  • liteDAS 是我们的抽样协议，旨在提供低延迟、带宽高效且稳健的抽样。
  • Dispersal（分散） 可以使用类似于 GossipSub 的协议来完成，但需要进行更改。
  • 通过确定性的托管分配和 Topic Routing（主题路由），我们可以快速找到对等节点以进行分散和抽样。
  • 为了启用抽样，我们还应该启用当前堆栈不支持的 Ephemeral Connect（临时连接）。
  • 2D encoding（2D 编码）（或一些其他的本地可修复代码）是 in-network-repair（网络内修复） 所必需的，这是 availability amplification（可用性放大） 的关键。

介绍

最初的 Danksharding 提案 目标是 32 MB 的区块，并且这个大小主要是由于 DAS 数据结构 中使用的 KZG 承诺的计算约束而选择的。自那时以来，网络设计经历了各种迭代，旨在有效地使区块数据在 P2P 结构中可用，并允许节点从此结构中进行抽样。然而，这些构造都没有令人信服地支持 32MB 的区块，这使得网络解决方案的性能成为真正的瓶颈。在这篇文章中，我们研究了这些网络问题并提出了解决方案，目的是使 32 MB（甚至更多）成为可能。

DAS：数据可用性 vs. 抽样

DAS（数据可用性抽样）的目标是以高概率确定给定的数据区块已提供给任何感兴趣的人，并且在不要求系统中任何单个节点持有（甚至临时接收）整个数据区块的情况下做到这一点。

也就是说，我们希望将各个节点的带宽需求保持在当前（EIP-4844 之后）以太坊网络的水平，同时处理大几个数量级的区块。从网络的角度来看，这是对以太坊 DAS 设计的一个重要约束。

对于我们关于网络方面的讨论，重要的是要强调 DAS 有两个不同的部分：“使数据可用”部分和“抽样”部分。

使数据可用

首先，必须使数据可用。可用性意味着系统中的节点获得“足够”的数据，以便能够共同重建原始区块。因此，可用性是 系统级别的属性：数据要么可用于整个系统，要么不可用。至少，这是我们想要实现的目标。

与一般的 P2P 系统一样，数据的量最好不要“刚刚好”，而应该是 非常足够，这意味着即使存在流失、网络分区或大部分恶意节点，也可以重建数据。只有在这一点上，我们才能说数据已被提供。

换句话说，我们应该设计一个协议，以确保没有临界情况：数据要么不可用（未被来源释放），要么非常可用。正如我们稍后将看到的，正是纠删码和稳健且高度冗余的 P2P 网络结构之间的相互作用使这成为可能。

抽样

其次，是抽样。抽样是单个节点对提供给系统的内容的看法。它是一个节点说服自己数据已被提供，并且它为此使用的技术是检索区块的几个部分。sample（样本） 是要检索的片段的（通常是随机的）选择，而 sampling（抽样） 是检索这些片段。如果此抽样成功，并且在一些 独立性假设 下，节点可以说服自己数据确实已被提供。

重要的是，在后台，在概率计算 背后，存在那些令人讨厌的独立性假设。基本上，假设数据是（过去是，或者将来是）独立于选择的样本而发布的。不幸的是，这可能会被利用，并且区块生产者及其“同伙”对节点的样本选择了解得越多，引入相关性从而愚弄某人就越容易。因此，sample selection（样本选择） 和 limited disclosure of the selection（对选择的有限披露） 是安全保证的重要组成部分。

注意：在这篇文章中，我们将区块的片段称为 segments（片段），但当使用 1D 编码时，它们也称为“column（列）”，当使用 2D 编码时，称为“cell（单元格）”，或者有时，令人困惑的术语“sample（样本）”既用于片段，也用于所选片段的列表。

另请注意，抽样并不是我们可以用来“说服自己”数据可用的唯一技术。在不尝试列出所有可能性的情况下，我们可以使用简洁的证明、受信任的朋友等。然而，抽样是无需信任的，并将数据片段传播到系统中的所有节点，最终实现额外的冗余层，从而实现恢复。

Interest（兴趣）：托管 vs. 样本

无论是在提供数据时，还是在节点进行抽样时，区块的片段都会传递到节点。但是，哪些片段传递到哪个节点是由这两个阶段中的不同目标驱动的。

我们称应该传递到节点的片段为它的 interest（兴趣）。系统中存在两种类型的兴趣。它们相似，但用途不同，并且存在一些根本差异：

  • custody（托管）：作为提供数据的一部分而传递到节点的片段被托管，并用于为抽样提供服务。也就是说，托管具有双重目标：提供可用性，同时充当抽样基础设施。
  • sample（样本）：抽样是为了让单个节点通过检查是否有足够的片段被托管，从而以非常高的概率说服自己可用性。

Interest（兴趣）可以 change over time（随时间变化），例如从 epoch 到 epoch 的样本选择，或者对于托管，还可能会有其他的时间粒度。改变它或保持它的固定性都对安全性和网络效率产生影响。

DAS 阶段：Dispersal（分散） vs. Sampling（抽样）

数据可用性和抽样的需求之间的根本差异，以及托管和样本的属性之间的差异，也反映在网络设计中。我们可以区分片段分布的两个阶段：

  • dispersal（分散）：其中区块的片段分布在 P2P 网络中，以提供非常高的可用性和托管。
  • sampling（抽样）：其中节点从托管处收集片段的随机样本。

这两个阶段可以使用不同的 P2P 网络结构。在下文中，我们重点介绍这些网络结构，为分散和抽样设计快速、稳健和带宽高效的协议。

FullDAS 网络

FullDAS - LossyDAS - liteDAS - 数据可用性抽样组件 FullDAS - LossyDAS - liteDAS - 数据可用性抽样组件960×720 80 KB

在最初的设计中，计划使用 GossipSub 进行分散，包含许多主题（512 个用于列，512 个用于行），将列和行分发到所有 stake 节点（带有验证器的信标节点）进行托管。相反，对于抽样，计划从所有完整节点（stake 和非 stake）设置一个单独的 DHT，为所有抽样查询提供服务。正如我们在相关的帖子和论文中强调的那样，这带来了一些挑战。

因此，在 PeerDAS 和 SubnetDAS 中，我们调整了设计以提供中间解决方案，在功能和可扩展性方面都做出了妥协。

在 PeerDAS 中，我们修改了托管分配和分散，使其基于 NodeID，使所有完整节点（stake 和非 stake）都成为托管系统的一部分。然后，使用节点现有对等节点的 Request/Response (Req/Resp) 协议从该 P2P 结构进行抽样，从而增加了对等节点发现 (Discv5) 以及节点必须维持的对等节点数量的压力。

相反，SubnetDAS 修改了设计，以始终使用 GossipSub 分发机制，用于分散和抽样。同样，这限制了我们的可能性，也牺牲了抽样查询的不可链接性。

即使对于几个 MB 的区块来说，这些的快速且带宽高效的实现也证明具有挑战性，这就是我们得出主要主题的地方：如何使 DAS 适用于 32 MB 及以上的区块？

在下文中，我们将介绍堆栈的重要部分：

  1. liteDAS：从托管处快速高效地抽样
  2. 快速查找托管对等节点：
    • 托管分配和样本选择
    • Topic Routing（主题路由）
    • Ephemeral Connect（临时连接）
  3. 使分散更有效
  4. 通过 2D 编码实现可用性放大

liteDAS：抽样协议

从抽象层面来说，抽样听起来很简单：

  • 抽取区块片段 ID 的随机样本
  • 向托管这些 ID 的节点请求这些 ID
  • 等待所有响应
  • 如果收到所有响应，则声明成功，否则声明失败

然而，实际上，事情变得复杂得多。在我们关于 LossyDAS、IncrementalDAS 和 DiDAS 的文章中，我们处理了一些与样本选择相关的复杂性，但我们在该文章中遗漏了所有网络方面的内容。

为了设计抽样协议，除了上面的草案大纲之外，我们还应该回答以下问题：

  • 节点应该何时开始抽样？
  • 抽样应该何时结束，超时时间应该设置为多久？
  • 如果我们知道有几个节点托管同一个片段，应该向哪个节点请求？
  • 如果我们不知道应该托管某个片段的节点该怎么办？
  • 抽样失败该怎么办？
  • 等等

此外，我们应该设计一种快速、稳健且带宽高效的协议。

对于抽样，我们提出 liteDAS，这是一种新的 Req/Resp 协议，旨在以接近最低的带宽使用量提供接近最低的抽样延迟，从而避免在正常路径和出现问题时过度利用资源。liteDAS 背后的关键观察结果是：

  • 没有“完美的时间”来请求片段，因为我们不知道分散何时会使这些片段到达托管。最好尽早请求并等待。
  • 抽样节点有一些时间（分散时间）来准备抽样。我们可以利用这段时间来提高抽样效率。
  • 如果我们逐个向不同的节点请求片段，我们可以更好地隐藏我们的样本。
  • 快速有效地查找给定片段的托管节点至关重要。

我们提出的 messaging primitive（消息传递原语） 是 带有显式超时时间的请求。这个简单的原语允许我们尽早开始抽样（在 slot 开始时），并且可以构建一个很好的动态行为，初始阶段用于处理正常路径，第二个阶段用于处理潜在问题，如下所述：

  • 在 T_0（slot 开始时，或者当公共参数已知时）

    • 使用本地随机性决定样本（片段 ID 列表）
    • 最终考虑使用 DiDAS 和/或 LossyDAS
    • 对于每个 ID：
    • 选择可能托管给定 ID 的候选对等节点列表
    • 选择 P=1 的这些候选节点（最终进行排名），并发送带有较长超时时间（例如 4 秒）的请求。P 是“parallelism（并行性）”参数。
  • 在 T_1=4 秒时
    • 对于每个仍然丢失的 ID
    • 选择下一个候选节点并发送带有较短超时时间的请求
    • 使用超时时间和未完成查询的数量来避免流量激增
    • 最终搜索新的候选节点（这也可以主动完成，在 T_1 之前）
    • 可选地，使用一段时间根据 IncrementalDAS 扩展样本

直观地说，这很快（将抽样延迟降低到接近最小值）、带宽高效（在正常路径上每个片段仅发送一个 Req/Resp）且稳健（一旦完成托管分配，便会探索抽样选项）。

快速

在 slot 开始时发送抽样查询使我们能够将抽样延迟最小化到分散延迟之上的单个 1 跳延迟（我们查询的节点接收到片段或列的延迟）。

更详细地说，为了理解为什么这很快，让我们看看最快的情况是什么。如果节点在知道它需要什么样本时，立即询问所有可能拥有该样本的对等节点，即计划托管该片段的所有对等节点，那么就可以实现最小的抽样延迟。然而，这意味着我们的节点会收到大量响应，从而增加了相当大的额外负载。在 liteDAS 中，我们一次只询问 P 个对等节点，这是带宽效率和延迟之间的折衷方案。 我们关于 GossipSub 延迟分布的数据 和我们最初的模拟表明，在正常路径上，延迟折衷方案非常有限。

带宽高效

该协议在正常路径上准确地接收每个样本（或列）一次。在非正常路径上，我们可以通过更改稍后阶段的 P 来在遵循具有较短超时时间的顺序逻辑或允许一些并行性（从而产生重复项）之间进行折衷。重要的是，如果数据实际上不可用，它仍会将资源利用率保持在限制范围内。

稳健

在第一阶段，上述抽样的稳健性依赖于分散的稳健性。分散已经采用了许多可靠性技术，因此，在正常路径上，对于每个 ID，我们选择的单个节点很可能收到样本。

相反，如果分散存在问题，我们的抽样对延迟的敏感性也会降低：无论如何，在通过托管广泛提供可用性之前，抽样都不应成功。因此，我们有时间“寻找”片段。在初始阶段之后，我们的协议将循环遍历可能托管同一片段的其他潜在对等节点。届时，我们还可以并行发送更多查询，最终允许一些重复项。

可能的扩展

除了基本思想之外，还有一些其他的调整可以改善动态行为：

  1. 节点可以预计到寻找可能提供给定片段的对等节点。这些是对等节点最终将托管该片段。
  2. 由于样本选择是使用本地随机性完成的，因此节点甚至可以提前准备样本（ID 列表），从而预计到对候选对等节点的搜索，无论是 slot 还是 epoch。
  3. 为了避免流量激增，我们建议控制未完成查询的数量以及超时时间。实际上，这意味着即使在区块不可用或存在大规模网络问题的情况下，我们也可以避免流量激增。
  4. 如前所述，一次询问一个节点是可行的，但这可以增加到例如并行询问 2 或 3 个节点。这些折衷方案甚至可以在本地进行，我们无论如何都无法真正强制执行它们。（实际上，我们可以使用类似于速率限制无效值的技术，但这超出了本文的范围，并且看起来太复杂了）。
  5. 我们还可以在查询响应消息中包含一个 HAVE 列表。其背后的原因是，它可以提供我们原本无法获得的有关扩散状态的额外信息。考虑到 1D 或 2D 结构，HAVE 列表可以很好地压缩成一个小型位图，因此它不会占用太多额外的字节。最终，为了保持消息原语的通用性，我们可以将其设为请求中的一个标志，以表明我们是否需要在响应中包含 HAVE 列表。
  6. 最后，值得一提的是，抽样节点可以使用在协议执行期间收集的信息，将片段反馈回托管。实现此目的的一种方法是引入一个带有 NACK（否定确认）样式消息的 Resp，当超时已过且片段未被托管时发送该消息。此“反向请求”意味着抽样节点应在从某人处收到该片段时发送该片段。

快速查找托管对等节点

liteDAS 仍然假设我们拥有要向其发送请求的对等节点。如果我们没有这些对等节点，并且我们必须搜索托管给定 ID 的对等节点该怎么办？如果我们在请求片段之前还必须完成复杂的连接过程该怎么办？

正如之前强调的那样，我们可以预计到对托管对等节点的搜索。尽管如此，有时我们确实需要搜索托管特定 ID 的对等节点，并且这应该相对较快。这是目前围绕 DAS 讨论中争论的关键点。作为抽样过程的一部分，我们需要在几秒钟内找到并连接到对等节点，这似乎是主要的限制因素之一。当构建用于高效的基于列（/行）的分发的网格时，分散也存在类似的问题，尽管在这种情况下，时间没有那么关键。

AgeManning 在 PeerDAS 规范讨论的一部分 中很好地总结了当前协议堆栈的问题。使用当前的堆栈从新对等节点获取单个片段的效率非常低。显然，这个问题有两个主要的潜在方面：

  • 查找节点效率低下：目前这将使用 Discv5 完成。由于 Discv5 没有主题搜索，因此它是 DHT 上的随机游走，枚举对等节点，希望找到一个好的节点。我们建议通过确定性的托管分配和我们所说的“主题路由”来加快此过程。
  • 连接到节点效率低下：我们打算通过引入“临时连接”来解决此问题。

基于确定性 NodeID 的托管分配

首先，让我们看看我们可以做些什么来快速找到给定片段的托管节点。关键在于明智地分配托管。

由于我们需要系统范围的可用性，因此必须正确分配托管，以提供良好的覆盖率。随机的本地选择可以提供这一点，但幸运的是，我们可以做得更好。托管的一个优点是我们 不需要隐藏谁托管什么。我们可以使用此属性，通过以确定性的方式 从 NodeID 导出托管兴趣（最终使用一些轮换方案并使用公共随机性），从而使我们的系统更加高效。似乎公开节点的托管兴趣不会影响安全性。似乎我们也可以提前公开披露兴趣（使托管在时间上保持稳定，类似于我们今天对证明所做的那样），并且这仍然不会产生安全问题。

请注意，这里有一个问题：通过使用 NodeID，我们没有像最初的提案那样将托管绑定到验证器，而是绑定到完整节点（包括未 stake 的节点）。因此，我们无法真正强制执行托管。我们目前无论如何都不想强制执行它，但稍后我们可能会引入 Proof Of Custody（托管证明），届时我们必须重新审视这一点。创建大量新 NodeID 也很容易，这可能会使托管面临有针对性的女巫攻击。

通过从 NodeID 导出托管，我们可以通过两种方式加快搜索速度。首先，我们可以从 nodeID 的最左边位导出托管。这使我们能够使用 Discv5 Kademlia 搜索而不是随机游走，因为 Kademlia 是基于前缀的。其次，如果使用托管轮换方案（节点会定期更改他们托管的列/行），我们可以从 NodeID 计算出这一点，而无需联系对等节点或从 Discv5 获取更新的 ENR 记录。

我们已经在 PeerDAS 中使用了这个基于 NodeID 的确定性托管分配技巧：它使我们能够使分散更有效，并且还允许抽样对等节点更轻松地找到托管节点，只需基于 NodeID 和与 ENR 中的 NodeID 一起发布的一小部分元数据即可。

请注意，样本的情况并非如此，我们确实关心使确定给定节点将对什么进行抽样变得相对困难，否则我们将很容易攻击单个节点。因此，我们无法从 NodeID 导出样本（片段 ID 列表），并且我们也最好避免将整个样本（再次，是 ID 列表，而不是数据）发送到单个节点。因此，我们更喜欢节点即时请求样本，最好有选择地向不同的对等节点公开兴趣，从而限制单个节点的暴露。

主题路由：高效地查找给定列或行的节点

我们掌握的另一个选择是直接将托管节点搜索引入我们的协议中，从而规避 Discv5 的困难。

在当前的提案中，列是使用 GossipSub 分发的，不同的列 ID 映射到不同的 GossipSub 主题。列 ID 空间被视为一个平面列表，而不考虑主题之间的任何关系。

然而，我们不必将行和列 ID 空间视为平面 ID 空间。我们可以使用几乎任何距离度量，并要求节点保持一些与其列/行 ID 接近的邻居，从而实现更快的搜索。以下是一些解释这可能如何工作的示例：

  • 循环：如果一个节点参与列 C，则它必须至少保留 N 个来自[C-D, C+D] mod NUM_COLS范围内的邻居，其中D和N是选定的
  • 超立方体样式：如果一个节点参与列 C，那么它必须保留来自列 C+2^j mod NUM_COLS 的至少 N 个邻居，其中 j in [0..log2(NUM_COLS}-1]
  • Kademlia 样式：如果节点参与列 C，那么它必须至少保留 N 个来自以下列集合的邻居：我们通过保持 j MSB（最高位）固定，并反转位 j+1 来获得该集合

第一个（循环）的可扩展性不是很好，最后两个具有良好的可扩展性。然而，如果我们将列数（和行数）保持得足够低，那么这些中的任何一个都足以找到任何 C 的潜在邻居。如果我们想扩展得更高，我们可能想选择最适合我们使用的那一个。

请注意，主题 ID 空间是密集的，每个 ID 代表一个主题，并且我们期望拥有的节点数量大于主题数量。相反，在典型的 DHT 中，密钥和节点 ID 在 ID 空间中是稀疏的。拥有密集的 ID 空间使我们能够简化搜索。

相对容易扩展上述任何一种技术来处理行和列，可以通过将列和行 ID 空间视为两个单独的 ID 空间，或者通过定义一个联合距离函数来实现。

另请注意，当我们在 2D 中进行抽样时，我们要么查找列 C 中的节点，要么查找行 R 中的节点。任何一个都足够了，这使我们的搜索更快。

临时连接：用于样本检索的快速连接

连接问题主要是由于协议限制造成的，因为我们在 libP2P 之上运行，而 libP2P 最初并非设计用于快速连接。我们通过严格限制连接的对等节点数量，并使许多节点的连接数量已满来使我们的生活更加艰难（众所周知，某些对等节点不接受连接，因此其他对等节点会过载，其对等节点计数已满，因此也不接受新连接）。

我们在下面列出了此问题的一些可能的解决方案：

  • libP2P-ephemeralConnect：我们可以向连接请求添加一个新标志，指示连接会快速超时。在接收端，这可以高于对等节点计数限制。
  • 使用 libp2p 框架之外的新原语：如果我们想要一个安全的加密协议，但又比 libP2P 修改更有效的东西，我们可以例如轻松地在这里重用我们的 Discv5 DHT 原语，在握手中发出 Discv5 请求。这仅需要 2 个往返行程和几个字节的数据。当然，这只是可以实现什么的一个例子。也可以导出具有类似延迟/带宽特征的其他自定义协议。
  • 查询转发：如果我们真的不想添加另一个原语，我们可以引入查询转发。一个节点可以根据主题路由选择它的一个对等节点，并将一个可转发的查询发送给它。我们将在 2 跳中获得样本。

我们认为这些可以解决连接问题，使我们能够实现 FullDAS。但是，还需要进行更多测试。

分散协议

最初，我们打算使用 GossipSub 进行分散，原因有几个。它是一种发布-订阅协议，可以很好地映射到纠删码结构，为每列（如果使用 1D 纠删码）或列和行（如果使用 2D 纠删码）创建单独的主题。它也经过了实战检验，已经在以太坊中用于区块扩散和证明聚合，显示出快速可靠的操作，如 我们相关的帖子测量区块扩散和证明的延迟分布 中所讨论的那样.

在 PeerDAS 中，我们实际上是将分散问题映射到相对少量的 GossipSub 主题。虽然这是一个合理的第一个方法，但有些方面是分散问题所特有的，并且允许进行性能优化。

使分散更加高效

我们已经使用 我们自定义的 DAS 模拟器 研究了区块可以使用多快的速度分散到托管中，无论是在 1D 还是在 2D 纠删码编码的情况下。正如我们在 EthereumZurich'23 的演讲 和后来的演讲 (EDCON'23, EthPrague'23, EthCC'23) 中所展示的，如果正确填充了列和行主题，GossipSub 可以在几秒钟内将区块数据分散到数千个节点。然而，在这些演讲中，我们提到 GossipSub-like 发布-订阅协议是有原因的。就目前而言，GossipSub 并不是我们拥有的最佳选择。我们认为我们可以进行一些更改，使其更好地适用于我们的情况。最终，我们也可能会导出一个专门针对分散用例的自定义协议。

在下文中，我们列出了 GossipSub 主题和分散的一般用途之间的一些可能差异，展示了一些可以进行的优化。我们将专门用一篇文章来详细扩展这些内容。

与通用的 GossipSub 主题相比，DAS “主题”的结构非常完善
  • 通过 512 行和 512 列的结构，我们可以将任何 ID 映射到 1+9 位（方向 1 位，位置 9 位）或 9+9 位的 ID 空间。
  • 然后，我们可以在消息 ID、HAVE 列表和许多其他数据结构中使用紧凑表示形式。
  • 鉴于紧凑的表示形式，我们还可以轻松地在其他消息上附带扩散状态信息。
通过多个主题，查找对等节点会变得很困难
  • 我们通过基于确定性 NodeID 的托管分配来部分解决此问题，
  • 部分通过基于主题 ID 接近度度量的“主题路由”来解决。
单个区块的 DAS 片段是无序的，我们可以利用这一点
  • 我们可以通过类似于“rarest first”的技术来加快传递速度。Rarest-fist 调度用于 P2P 传播中，以减少延迟分布的尾部，从而均衡不同片段的扩散。Rarest-first 需要精确的“have”信息，这通常是不可用的，但可以进行近似。例如，我们在模拟器中已经实现的一项技术是确保在将每个片段的第二个副本发送到另一个邻居之前，区块生产者会发送每个片段的副本。我们首先仅将每个片段的一个副本发送到区块生产者的列/行邻居之一（随机），在网络中的随机位置播种片段。只有这样，我们才能将第二个副本发送到其他对等节点。稍后，可以使用通过例如 IHAVE 位图收集的信息来估算哪些片段扩散良好，哪些片段似乎受到阻碍，从而根据此信息优先考虑进一步的播种。
  • 我们还可以通过“节点着色”技术来加快传递速度：这些技术是关于专门化节点以优先考虑它们托管的 ID 空间的特定子集的分配。
通过 TCP，我们需要支付按顺序可靠传递的成本
  • GossipSub 默认使用主题网格上按顺序可靠传递，这具有固有的成本。
  • DAS 不需要片段之间的排序（相反，混排是有益的）。
  • DAS 不需要 P2P 链接级别的可靠性（因为我们拥有所有其他可靠性技术：多路径、EC、拉取、列和行之间的交叉反馈）。
  • 因此，使用例如随机化的尽力而为的传递可以提供总体上更好的性能。
重复项减少技术
  • 使用 GossipSub，我们需要支付相对较高的重复传递的带宽成本。基本上，每条消息至少遍历每个主题网格链接一次。有时甚至两次，当从双方在时间上接近发送时（小于单向延迟）。这意味着平均而言，每条消息至少发送 D/2 次，其中 D 是目标网格度数。
  • 这些重复项有多种用途：有助于稳健性、低延迟和保护发送者身份。但是，在 DAS 中，我们不需要保护发送者身份。由于流量量，我们无法保护它。这以及我们并行地通过多个主题进行分配的事实，允许进行优化。
    • 一种选择是使用 IDONTWANT 提案
    • 我们还可以使用基于扩散状态的技术，例如 Push-Pull 相变：在片段扩散的最初步骤中，几乎没有重复项。大多数重复加载发生在扩散的最后步骤中。人们可以在开始时强调 Push（甚至增加一个度数，发送到比没有此技术时更多的节点），并且如果可以估计扩散状态，则在扩散结束时更改为 gossip-and-pull。

2D 编码的需求：通过网络内修复实现可用性放大

在 DAS 描述中，纠删码主要被用作一种使抽样更稳健的工具。然而，我们应该强调的是，我们可以在设计中使用纠删码来实现两个目的：

  1. 放大抽样，以及
  2. 放大可用性。

放大抽样 很容易理解：使用比率 R=K/N（例如 1/2）的代码，并假设数据不可用，则每个抽样的片段都将无法发现数据不可用的机会降低了 2 倍。我们喜欢这种指数属性，它使我们仅通过抽样几个片段就可以达到非常低的误报 (FP) 率。在 2D 情况下，比率不如 1D 好，但我们仍然具有很好的指数属性。

放大可用性 是一件不同的事情。这意味着，如果数据可用，我们会使其非常可用。我们通过在分散期间使用 in-network repair（网络内修复） 来实现此目的。这是我们的纠删码结构和分散网络结构交汇的地方。通过根据代码（在列和行中）来组织节点，并通过使节点同时参与行和列，我们可以在分散期间启用 EC 结构中的本地修复。

正如我们在 EthereumZuri.ch'23 讨论 中的模拟中已经展示的那样，这种网络内修复正在放大可用性。基本上，如果没有发布足够的样本，则网段计数将保持在 75% 以下，而验证器和许多构造中的完整节点使用的基于行/列的抽样 (SubnetSampling) 仍然非常低。网段抽样也仍然非常低。

相反，如果发布了一个以上的网段，其结果将通过分散结构放大到几乎 100%。

然而，为了使这种放大机制起作用，我们需要 2D 代码。我们无法在 1D 情况下真正做到这一点，因为在 1D 情况下，只能在拥有 K 个片段的节点中进行修复，基本上是整个区块。相反，在 2D 情况下，我们可以在任何单个行或列中进行修复，因此各个节点可以修复然后发送。换句话说，我们需要具有本地修复能力的代码。我们可以使用 2D RS 制作这样的代码（如果我们愿意，还有其他具有本地修复能力的代码构造）。

因此，虽然我们可以通过多种方式将网段 ID 映射到托管，但我们通过列和行来执行，以在分散期间启用网络内修复和可用性放大。

结论

我们撰写本文的目的是概述 FullDAS 的主要构建块，这是我们为具有 32MB 或更大的区块的 DAS 提出的网络堆栈。我们讨论了将区块数据分散到托管 P2P 结构中的新方法，同时还放大了数据的可用性。我们还展示了使用 liteDAS、主题路由和改进的连接机制，从此结构实现快速、带宽高效和稳健的抽样所需的工具。

在这一点上，很多人可能很明显，我们正在构建类似于 DHT 的东西，过去曾多次提出这一点：分散到托管和抽样之间的区别，以及 DHT 的通用概念并没有那么大。使用 FullDAS，我们实际上正在构建一个专用分布式存储结构，具有自定义播种、修复和检索，每个都针对 DAS 编码和 DAS 目的进行了优化。

以上一些技术已经在模拟中进行了评估，而另一些技术正在进行中。我们为此目的编写了两个模拟器：

  • 一个具有较高抽象级别，用 Python 编写，用于大规模实验。在此，协议行为是近似的，但可以探索更大的参数空间。
  • 另一个具有较低抽象级别，直接使用 nim-libP2P 堆栈。我们已经使用此模拟器来模拟具有修改后的 GossipSub 实现（具有 128 列和 128 行）的扩散，并从此结构运行到 1000 个节点的抽样。

这两个都在进行中，我们计划在 FullDAS 协议的改进和评估继续进行时发布更多帖子。

引用

最初的 Danksharding 提案 DAS 数据结构

我们之前关于采样技术的文章：LossyDAS, IncrementalDAS, 和 DiDAS

使用 Kademlia DHT 进行 DAS 的可扩展性限制

PeerDAS 提案

SubnetDAS 提案

我们关于测量 GossipSub 延迟分布的文章，包括用于区块和用于证明时

关于对等搜索和连接问题的 PeerDAS 规范讨论的部分

托管证明

我们之前关于 DAS 的演示文稿：

我们的 DAS 模拟器：

  • 原文链接： ethresear.ch/t/fulldas-t...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文， 用中文传播以太坊的最新进展

以太坊中文

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！