从 4844 到 Danksharding：以太坊 DA 扩展的路径 - 网络

这篇文章源于许多研究人员和客户端开发人员之间关于将 DA 层扩展到 EIP-4844 之外的方法的持续讨论，旨在总结并使一些流行的想法易于理解。PeerDAS 建议首先阅读。

感谢 Danny Ryan、Ansgar Dietrichs、Dankrad Feist、Jacob Kaufmann、Age Manning、Csaba Kiraly、Leonardo Bautista-Gomez 提供的反馈和讨论。

EIP-4844 是扩展以太坊数据可用性层探索中的第一个里程碑。 它引入了一种新型资源，blob 数据，具有其自身独立的费用市场，以及数据可用性采样 (DAS) 所需的许多加密组件（KZG 仪式、承诺和证明）。 目前，完整节点仍然下载所有数据，4844 的可扩展性提升归功于两个因素：

• 独立的费用市场，可防止 blob 数据和执行成为竞争资源。 这确保了所需的 blob 数据吞吐量得以实现，而无论 L1 执行的需求有多大。
• 几周后 blob 的修剪，这使得额外的存储成本是固定的，而不是随着时间的推移而增加。

为了在保持或降低资源需求的同时进一步提高吞吐量，需要每个节点仅下载一部分数据，这意味着引入某种形式的 DAS，正如 Danksharding 提案的目标一样。 鉴于其雄心勃勃的性质，我们认为最好将从 4844 到 Danksharding 的道路进一步分解为更易于管理的步骤，从而降低每次升级的复杂性和风险，并允许我们逐步扩展数据层吞吐量。

一条可能的路径是经过中间阶段，在这些阶段中，我们逐步引入所有加密和网络组件，并逐步获得更多的可扩展性和功能完整性，同时与 4844 相比，最多只会略微增加带宽需求。 第一步可能是引入基于 PeerDAS 的 1D DAS 结构，这将降低复杂性，并且仍然可以实现比 4844 显着更高的吞吐量。 那么，从原则上讲，过渡到最终的 2D 结构相对简单，并且一旦所有加密组件都准备就绪，就可以实施。 除了这两个较大的升级之外，只要准备就绪，就可以引入诸如分布式重建之类的功能，并且随着网络的改进以及我们从观察系统按预期工作所获得的信心，可以将吞吐量逐渐扩展到理论最大值。 从 rollup 及其用户的角度来看，这一切都应该被视为 blob 数量的逐渐增加，就像执行层上 gas 大小的逐渐增加一样。

阶段概览

• 阶段 0：EIP-4844。 引入子网来分发 blob，但节点必须参与所有子网，下载所有数据。 没有 DAS。

• 阶段 1：1D PeerDAS。 Blob 在水平方向上进行 1D 扩展。 Blob 分发是分片的：引入列子网，节点仅参与其中的一部分。 Blob/行子网此时可能会被弃用。 引入了对等采样的网络组件：发现采样对等方以及通过 req/resp 协议进行对等采样。 节点对列执行 DAS，并且它们参与的列子网的数量是这样选择的，以便节点的对等集可以可靠地覆盖所有列。 在这个阶段内，我们可能期望最大 blob 数量从 32 逐渐增加到 64，甚至可能增加到 128。

2936×2208 261 KB

• 阶段 2：2D PeerDAS，或完全 Danksharding。 我们实现完全 Danksharding，特别是采样基础设施是对等采样。 Blob 被 2D 扩展，添加了垂直扩展。 对等采样现在利用扩展矩阵中的单元格而不是列，从而变得轻量级，带宽消耗可忽略不计。 可以支持不参与分发的轻型采样节点。 分布式重建（如果/何时实施）对于子网故障的鲁棒性更高。 在这个阶段内，我们可以预期 blob 计数从 64 甚至可能 128 开始，并逐渐增加到 Danksharding 的最大吞吐量 256。

image3020×2840 276 KB

• 并行进行：
  • 分布式重建： 可以在准备就绪的任何时候实施，无论是在 1D 还是 2D 阶段。 在 1D 阶段，我们将重新引入行子网并允许在其中传播单个单元格，以便可以重建和重新播种 blob。 在 2D 阶段，这也将适用于列子网，从而产生一个对单个子网故障具有鲁棒性的系统（1D 结构中缺乏垂直冗余意味着行子网的故障完全阻止了重建）。 在实施之前，重建将依赖于下载整个数据的节点，在本地重建并重新播种它。 特别是在最初较低的 blob 计数（32 到 64）时，这是一项非常容易实现的任任务，因此没有太多的假设。 在任何情况下，我们只依赖 1/N 的诚实性假设。
  • 网络改进： 对于对等采样而言，最重要的是支持更高的对等方计数，因为这解决了其主要的短期扩展瓶颈（长期瓶颈是分发）。 我们或许最终还可以支持一种更轻量级的仅采样对等方，除了偶尔的 ping 之外，开销非常有限，原则上让节点在寻找样本时可以访问整个网络。
  • 未来扩展的研发： 我们可能在某个时候想要更改采样机制或引入替代采样路径来补充对等采样，例如使用 DHT，以实现更高的弹性并减少对采样提供者的依赖。 尽管如此，进一步的扩展（吞吐量与带宽之间更好的比率）需要改进数据分发阶段，因为这是带宽瓶颈，尤其是在我们转向 2D 结构之后。 一些收益可能来自子网基础设施本身的改进，但是可以实现的目标是有限的，因为 1/n 的子网密度（每 n 个节点中有 1 个节点在每个子网中）需要节点下载 1/n 的整个数据。 需要进行更彻底的重新设计才能对此进行改进。

阶段 1：1D PeerDAS

数据格式

Blob 在水平方向上单独扩展，垂直堆叠并细分为 NUM_COLUMNS 列，这些列用作采样单元。 NUM_COLUMNS 决定了最大列大小，从而决定了采样消耗多少带宽（对于给定的可靠性，即样本数量）。 在下文中，我主要考虑示例参数 NUM_COLUMNS = 128，这意味着最大样本大小为 256*b/128 = 2b KBs，对于 MAX_BLOBS_PER_BLOCK = b（扩展 blob 为 256 KBs）。

分发

每列都映射到 NUM_COLUMN_SUBNETS GossipSub 主题之一，我们将其称为列子网，并在其中分发。 行子网可能暂时可以弃用，并在实施分布式重建时重新引入。 我们要求每个节点至少参与 CUSTODY_REQUIREMENT 列子网。 CUSTODY_REQUIREMENT/NUM_COLUMN_SUBNETS 然后指示每个节点保管的最小数据量，这也是最小的子网密度。 正如我们将看到的，这是带宽消耗的最重要组成部分，因为它会产生 GossipSub 主题的放大因子（而通过 req/resp 进行采样则不会），并且当移动到 2D 结构时，采样最终会变得非常便宜。

从子网密度的角度来看，此比率的一个安全选择可能是 1/64，因为我们已经在使用证明子网中具有此子网密度的经验，但是我们可能可以接受 1/128。 另一方面，正如我们很快将在本节中看到的，如果该比率较高，则对等采样更可行，如果 NUM_COLUMN_SUBNETS 尽可能小，即 CUSTODY_REQUIREMENT = 1，则更好。 那么，我们可以从 NUM_COLUMN_SUBNETS = 32、CUSTODY_REQUIREMENT = 1 开始。

注意：对于给定的比率，设置 CUSTODY_REQUIREMENT > 1 的一个可能原因是 1/NUM_COLUMN_SUBNETS 决定了最小的“保管单元”，我们可能希望节点在保管量方面具有更大的灵活性（超出要求的最小值）。 例如，如果 NUM_COLUMNS = 128，NUM_COLUMN_SUBNETS = 32 和 CUSTODY_REQUIREMENT = 1，则最小保管单元（在本例中与最小要求的保管量相对应）为 4 列，而想要保管超过最小值的节点必须保管 8 列，然后是 12 列等... 如果 NUM_COLUMN_SUBNETS = 64，CUSTODY_REQUIREMENT = 2，则该比率仍为 1/32，最小要求保管量仍为 4 列，但最小保管单元仅为 2 列，因此可以保管 6、8、10 列等... 设置 CUSTODY_REQUIREMENT > 1 的另一个原因是，正如我们将在本节中看到的，分发阶段已经提供了其自身的一些有意义的安全保证，无需采样。

对等采样

如 PeerDAS 文章 所述，样本是通过 req/resp 从对等方获得的，除了这里的样本是整个列，或者更准确地说列辅助对象。 在本节中，我们讨论了此对象的详细信息，包括允许对其进行验证的随附数据。 对等方的选择基于他们保管的列，这可以从他们的 ENR 中确定，ENR 是他们声称所在的子网数量（可能超过要求的最小值）、其节点 ID 以及可能的纪元的函数。

扩展对等采样

PeerDAS 可实现的吞吐量不仅取决于可用的带宽，还取决于完整节点的对等集组成，因为节点的对等集应覆盖所有样本，理想情况下应具有足够的冗余度以应对不可靠甚至纯粹恶意的对等方。 覆盖所有样本需要覆盖所有子网，因此对等采样可以支持的 NUM_COLUMN_SUBNETS 取决于节点拥有的对等方数量以及每个节点参与的子网数量。 这正是我们可能希望保持 NUM_COLUMN_SUBNETS 较低的原因，低于我们仅为了保持足够高的子网密度而需要的水平。 这可能是我们可以支持的 blob 数量的限制因素，因为它对分发所需的带宽设置了更高的下限。 实际上，这可能意味着我们需要随着网络优化允许更高的对等连接数量而逐渐提高吞吐量（blob 数量），甚至可能通过引入一种开销非常有限的更轻量级采样对等类型来实现。

但是请注意，如果我们乐于依赖少量诚实的超级节点或部分超级节点（即，保管超过要求的最小值甚至所有数据的节点），那么我们很可能从第一天就可以将 PeerDAS 扩展到其理论极限。 更笼统地说，更实际地了解我们可以将对等采样扩展到多远，需要考虑到网络上节点的异构性，这会影响他们愿意保管和提供的数据量。 在一个非常异构的网络中，我们可以用较低的对等连接数量来应对平均节点。 正如已经预料的那样，在下文中，我将假设 NUM_COLUMN_SUBNETS = 32，CUSTODY_REQUIREMENT = 1 在实践中是一组可行的参数。

子网采样和对等采样之间的权衡

通过子网采样，我们的意思是设置 CUSTODY_REQUIREMENT 足够高，以便分发阶段已经提供了一定的安全保证，甚至在进行对等采样之前（或者实际上根本没有对等采样，如 SubnetDAS 中的情况）。 特别是，我们可以保证，如果少于 50% 的所有列可用，则只有一小部分节点会接收到他们参与的子网上的所有数据。 换句话说，即使在分发阶段，也只有一小部分节点会被欺骗，认为不可用的数据是可用的。

在这里，“小百分比”的含义在很大程度上取决于 CUSTODY_REQUIREMENT。 例如，假设攻击者使列 [0,59] 可用，略小于一半。 如果 CUSTODY_REQUIREMENT = 1 且 NUM_COLUMN_SUBNETS = 32，则前 15 个子网中的诚实节点将收到所有辅助数据并对关联的区块进行投票，因此几乎 1/2 的诚实投票者最初会投票支持不可用的区块。 通常，即使是幼稚的攻击者也可以轻松地欺骗 2^{-k} 的所有诚实节点，如果 CUSTODY_REQUIREMENT = k，因此从分发阶段获得任何有意义的安全性都要求 CUSTODY_REQUIREMENT 至少为 ≥ 4。 对于自适应攻击者来说，这可能仍然不够，因为自适应攻击者会通过观察节点在子网上的确切分布来精确地选择要公开可用数据的哪一部分，如此处所述。 在这种情况下，如果 CUSTODY_REQUIREMENT = 4 且 NUM_COLUMN_SUBNETS = 128，则可能被欺骗的诚实节点比例的上限约为 20%。 如果 CUSTODY_REQUIREMENT = 6，则该值将低于 10%。

原则上，我们可以始终将 CUSTODY_REQUIREMENT 和 NUM_COLUMN_SUBNETS 乘以相同的因子，保持相同的比率，因此保持相同的子网密度和相同的分发带宽消耗，同时提高子网采样的安全保证。 但是，这与对等采样的可行性之间存在权衡：即使我们保持相同的比率，增加 NUM_COLUMN_SUBNETS 也意味着增加节点需要覆盖所有子网的诚实对等方的数量，因为存在更多重叠。 在较低的对等连接数量下，这可能会使其难以支持提供有意义安全级别的 CUSTODY_REQUIREMENT，这对分叉选择和确认规则产生了一些影响，我们现在将看到。

分叉选择

我们需要更改 is_data_available 函数。 一种可能性是在插槽 n 执行以下操作：

• 为了确定与插槽 n 中的区块关联的 blob 数据的可用性，我们使用我们参与的列子网中数据的可用性：如果我们收到了所有辅助数据，则我们认为该数据可用。
• 为了确定与插槽 < n 中的区块关联的 blob 数据的可用性，我们使用对等采样结果：如果我们获得了所有请求的样本，则我们认为该数据可用。

这样，插槽 n+1 的提议者至少有 8 秒（证明截止日期和下一个插槽之间的时间）来执行对等采样，而插槽 n 的证明者只需在证明截止日期之前收到区块和关联的列辅助数据即可，就像 4844 中的 blob 辅助数据一样。

可能的分叉选择攻击向量

采用这种后续 DA 过滤器的不利之处在于具有较低的 CUSTODY_REQUIREMENT，是因为对最近区块的投票无法完全信任，因为由于我们在上一节中讨论的原因，许多诚实的验证者可能会被欺骗而投票支持关联数据不可用的区块。 当然，这只是暂时的，因为如果数据保持不可用且对等采样失败，则没有诚实的投票者会在以后的插槽中继续投票支持这样的区块。 尽管如此，还是可能发生一些微妙的分叉选择攻击，例如：

1. 与插槽 n 提出的区块 B 关联的 Blob 数据以有针对性的方式发布，以便获得许多诚实的证明者投票支持区块 B，即使 blob 数据实际上不可用，也要利用较低的 CUSTODY_REQUIREMENT。
2. 提议者插槽 n+1 执行对等采样，发现数据不可用并提出一个不扩展区块 B 的区块 B'。
3. 与此同时，与区块 B 关联的数据变得可用，并且插槽 n+1 的证明者不投票支持 B'，因为它不扩展 B，B 是可用的并且得到了来自插槽 n 的证明者的很多支持。

为了完全阻止或使此攻击更加困难（要求攻击者控制更多的证明者），我们可以要求插槽 n+1 的证明者在插槽 n 结束前的某个时间（例如，在插槽 n 的 10 秒后）记住对等采样的结果，并在插槽 n+1 的分叉选择中使用该结果，除非它与提议的区块不一致。 如果你熟悉以太坊的共识研究，这应该会让你想起视图合并技术，尽管复杂度要低得多，因为不需要来自提议者的额外消息。 这样做的不利之处在于我们收紧了执行对等采样的窗口。

带宽要求

假设目标和最大带宽约束与 4844 相同，即我们平均希望每个插槽需要相当于 3 个 blob，最大为每个插槽 6 个 blob。在 8 倍放大因子的情况下，这相当于每个插槽 ~3/6 MB。对于 MAX_BLOBS_PER_BLOCK = b，让我们考虑参与最小 CUSTODY_REQUIREMENT = 1 子网（每个子网包含四列）的节点的最大带宽消耗：

• 列分发： 由于分发通过 GossipSub 主题进行，因此就像 4844 中的 blob 子网一样，它会产生放大因子。每个单元格为 256/128 = 2 KB，每列为 2b KB。对于 MAX_BLOBS_PER_BLOCK = 64，列 then 为 128 KB，因此列的传播相当于 4844 中一个 blob 的传播。那么一个子网会占用我们预算中的四个 blob。
• 对等采样： 剩余的带宽预算相当于两个 blob，或 2*128*8 = 2048 KB（考虑到放大因子）。这足以用于最多 k = 2048/128 = 16 个样本，因为 PeerDAS 中的采样通过 req/resp 进行，因此不会受到放大因子的影响。当节点未被攻击者专门针对时，这给出的可靠性为 2^{-16}，否则给出全局安全保证，即没有攻击者可以说服超过 \approx 2-3% 的节点，不可用的数据是可用的（有关更多说明，请参见此处和SubnetDAS 文章）。这些安全保证可以说是相当充分的，我们不需要采样更多。

一些评论：

• MAX_BLOBS_PER_BLOCK = 64 是当前 4844 吞吐量的 10 倍，并且完全在带宽预算内，而不需要较高的 NUM_COLUMN_SUBNETS，这意味着我们不需要特别关注对等采样的可行性，或者过度依赖采样提供商。 安全的路径可能是从 MAX_BLOBS_PER_BLOCK = 32 开始，并随着我们确定网络可以处理负载而逐渐扩展到 64。
• 扩展到 MAX_BLOBS_PER_BLOCK = 128 可能需要将 NUM_COLUMN_SUBNETS 增加到 64。支持如此高的 blob 计数可能在很大程度上取决于网络中是否存在许多超级节点，和/或需要支持更高的对等连接数量。
• 此时，分发和采样对带宽负载的贡献相似。 如果增加 NUM_COLUMNS，则可以减少采样的影响，例如，NUM_COLUMNS = 512 意味着采样消耗半个 blob（如果 MAX_BLOBS_PER_BLOCK = 64）和 1 个 blob（如果 MAX_BLOBS_PER_BLOCK = 128），比分发少 8 倍。 如果我们可以接受比 4844 增加 50% 的带宽（最高 9 个 blob），这已经足以支持 MAX_BLOBS_PER_BLOCK = 128 而无需增加 NUM_COLUMN_SUBNETS。 此外，通过移动到 2D 结构，采样使用的带宽可以低于吞吐量（并且实际上可以忽略不计）。 这使得分发成为最终的瓶颈，并随着数据吞吐量线性扩展（对于最小子网密度）。

网络级验证

如 PR#3531 中所示，我们希望能够在分发阶段执行网络级验证，而无需等待区块到达。 这样，区块和辅助数据的传播实际上可以并行发生，而不是后者必须等待前者。 理想情况下，我们希望继承区块的可罚没性保证，这意味着提议者（或任何其他人）无法传播与区块中的承诺不匹配的辅助数据，而无需双重签名，即使是对尚未收到区块的节点也是如此。 在 EIP-4844 中，当前解决方案（来自上述 PR）是在 blob 辅助数据中包含相关的 kzg_commitment，以及 kzg_proof、区块头和针对其 body_root 的包含证明，表明 kzg_commitment 的确包含在区块主体中的 blob_kzg_commitments 列表中。 这样，验证只涉及检查 kzg 证明，这确保了 kzg_commitment 与 blob 匹配，以及包含证明。 可罚没性保证继承自区块头。

在这里，我们可以遵循非常相似的策略，旨在将区块头、承诺和包含证明与区块分开分发。 我们可以将当前用于 blob 辅助数据的方法应用于列辅助数据，即在列子网上分发的对象。 在这种情况下，每个列辅助数据都需要包含所有承诺，因为它们都是验证所必需的。 它还将包含区块头、包含证明（证明 hash_tree_root(blob_kzg_commitments) 包含在 body_root 中，即包含整个承诺列表而不是特定列表。此证明的深度为 4）以及列的所有单元格证明。 然后可以使用承诺和证明来批量验证列。

这种方法的优点是列辅助数据没有外部依赖性，因此可以在收到后立即进行验证和转发，这意味着区块和关联列的传播可以真正并行发生。 出于同样的原因，采样可以立即开始，而无需等待区块或其他列辅助数据到达。

缺点是区块头、包含证明和承诺在每个列中都会重复。 尽管如此，请注意，前两个可以忽略不计，并且每个列从承诺中每行仅获得额外的 48 字节，以及从单元格证明中每行获得额外的 48 字节。 如果 NUM_COLUMNS = 128，则一个单元格为 2 KB，因此这大约是带宽增加 5%。 另请注意，包含证明只需要检查一次，而不是每列检查一次，因此唯一的损失实际上是带宽的少量增加。

过渡

准备好从阶段 1 过渡到阶段 2 主要需要充分了解的组件，即用于分发的 GossipSub 主题（又名子网）和用于采样的对等方之间的 req/resp。 大多数更改都不需要硬分叉，因为它们要么在网络中，要么在分叉选择中。 唯一需要做的更改是增加 blob 计数，这也可能在所有其他更改都已到位之后发生，也就是说，我们可以在仍然具有 4844 blob 计数 3/6 的情况下从阶段 0 过渡到阶段 1，并且仅在以后增加此计数。 实际上，无论如何我们都希望在协调点执行网络和分叉选择更改，因此将所有更改与硬分叉捆绑在一起可能是有意义的。 一旦发生向阶段 1 的第一次过渡，我们就可以在随后的任何硬分叉中逐渐增加 blob 计数（或使用其他机制，如果需要）。

阶段 2：2D PeerDAS

数据格式和分发

Blob 在水平和垂直方向上都进行了扩展。 生成的矩形仍然细分为 NUM_COLUMNS 列，并且样本现在是单元格，即行和列的交集，如 Danksharding 构造中所示。 分发中没有任何更改。

对等采样

采样仍然利用相同的网络构建块，即发现不同的对等方集（关于他们参与的子网）以及 req/resp 来从他们那里采样。 唯一的区别在于请求的对象是什么，即单元格而不是列。 单元格带有随附的证明，要针对相应行的 KZG 承诺进行验证。

带宽要求

让我们考虑 MAX_BLOBS_PER_BLOCK = 256，这将实现最初计划的 Danksharding（最大）吞吐量 32 MB/插槽，尽管实际上我们可能会逐渐增加 blob 计数以达到这一点。 在此阶段，让我们假设我们能够将 NUM_COLUMN_SUBNETS 增加到 64，这可能是因为对等连接数量增加。

那么每个子网将包含两列，每列的权重为 1 MB。 尽管如此，列辅助数据仅重 0.5 MB，因为它只能包含列的前半部分，而其余部分可以由接收者在本地重建。 这样做包括大小为 2^{14} 的一个 FFT，以从求值形式转换为系数形式，以及另一个相同大小的 FFT，以恢复扩展的求值形式（arkworks 中约 4 毫秒）。 那么，列子网消耗相当于 8 个 blob 的带宽预算，这比 4844 的 6 个略有增加。传播动态可能有所不同，因为对象更少、更大，但这可以通过增加 NUM_COLUMNS 轻松更改。

采样所需的总带宽仅为 2k KB，因为样本的权重仅为 2 KB，而不是 1D 构造中的 2b KB。 正如预期的那样，即使 k = 75（这给出的可靠性约为 \approx 2^{-30}），与分发所需的带宽相比，用于采样的带宽实际上可以忽略不计。

网络级验证

阶段 1 中的相同方法在这里也适用。 即使使用垂直扩展，也需要与列辅助数据一起发送的证明和承诺的数量原则上也不会改变，因为第二列的证明和承诺都可以通过线性组合那些用于前半部分的证明和承诺来重建，因为证明和承诺都是同态的。 尽管如此，我们可能会选择仍然发送所有证明以避免重建步骤，在这种情况下，列辅助数据现在将包含 2b 个证明，从而导致额外消耗 2.5% 的带宽（对于 NUM_COLUMNS = 128）。

过渡

准备好从阶段 2 过渡到阶段 3 需要高效地实现 2D 加密，但这主要影响区块生产过程。 对等采样也略有变化，因为通过 req/resp 协议交换的对象从列更改为单元格。 原则上，再次只需要硬分叉来增加吞吐量，因为区块仍然只包含相同的 KZG 承诺列表，即与实际 blob 对应的 KZG 承诺，而不是与扩展行对应的 KZG 承诺（如前所述，我们可以从前者重建后者）。 我们仍然需要所有更改都发生在协调点，因此它们可能仍然与硬分叉结合在一起。

• LossyDAS：用于数据可用性的有损、增量和对角线采样
• PeerDAS -- 一种使用经过实战检验的 p2p 组件的简单 DAS 方法
• DAS 分叉选择
• 使用 FullDASv2（包括 getBlobs、mempool 编码和可能的 RLC）加速 blob 扩展
• 动态 Blob 大小调整：减少小 Rollup 中的零填充开销

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