将证明计算从信标节点转移到交易发送者

jimmygchen
发布于 2025-02-21 11:27
阅读 208

文章讨论了EIP-4844之后，在PeerDAS中验证样本时面临的KZG证明计算瓶颈问题，并提出将cell的KZG证明计算转移到交易发送者的解决方案。这种方式可以移除区块生产过程中节点计算KZG证明的需求，从而提高blobs数量的可扩展性，并可能在Fusaka fork中实现。

**TL;DR（太长不看）**

- 通过 EIP-4844，交易发送者计算 KZG 证明，并将其与 blob 交易一起发送。
- 在当前的 PeerDAS 设计下，验证样本需要在样本（单元格）级别进行 KZG 证明，目前这些证明是在 CL 中计算的，以避免将 DAS 密码学泄露给 EL。然而，这会造成计算瓶颈，并限制可扩展性。
- 提出的解决方案将此计算转移到交易发送者，因此他们为每个单元格计算 KZG 证明，而不是每个 blob，从而无需节点在区块生产窗口中计算任何 KZG 证明。

## 介绍

![image](https://img.learnblockchain.cn/2025/06/05/HyC8hf3K1e.png)

_(来源: [Dune](https://dune.com/hildobby/blobs))_

今天我们需要更多的 blob，明天需要更多。

当前形式的 PeerDAS 能否扩展到 1D PeerDAS 的理论极限 - **最多 64 到 72 个 blob？** 简短的回答是**不太可能**。

有一些已知的瓶颈，而且我们甚至不确定扩展到 32 个 blob 是否安全（更多内容见下文）。如果我们从保守地增加 Fusaka 开始 - 比如最多 16-18 个 blob - 我们必须等到 G 分叉（2026-2027）才能再次增加它。这可能太迟了，并降低了现在推动 PeerDAS 的价值。

_(除非我们有 [BPO 分叉](https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623) 以允许我们在分叉之间更改 blob 计数)_

在这篇文章中，我们将探讨一种解决方案，该解决方案使我们能够进一步（可能达到 1D PeerDAS 的理论极限）和更安全地扩展 blob 计数，并提出一个案例，将其在 Fusaka 分叉中发布。该解决方案在 DevCon 期间进行了讨论，并由 Francesco 倡导将其与 PeerDAS 一起包含。

## 问题

如今在主网（Deneb）上，发送 blob 交易 (EIP-4844) 需要交易发送者包含计算出的 KZG 承诺和证明作为原始交易的一部分。该承诺确保无法替换虚假的 blob 数据，并且 blob 证明在交易进入 mempool 时在执行层 (EL) 中验证，并在通过网络传输时在共识层 (CL) 中验证。

从 PeerDAS 升级开始，blob 数据在共识层中的网络形式发生变化 - blob 数据将以 `DataColumns` 的形式发送，`DataColumns` 由 `Cells` 组成，每个单元格都附带一个证明[\[1\]](#fn1)，节点将使用这些证明（而不是来自 Deneb 的 blob KZG 证明）来验证所有传输的单元格与 KZG 承诺。

在当前的规范中，这些单元格 KZG 证明由提议者在区块生产期间计算。计算这些证明非常昂贵，对于单个线程上的每个 blob 约为 **~150ms**，但可以并行化。这已经成为一个已知的瓶颈一段时间了，并且已经有新的优化来降低这个数字，包括优化 KZG 库的性能和[分布式 blob 构建](#Appendix-2-Distributed-Blob-Building-Refresher)。

这将允许我们在不增加完整节点硬件和带宽要求的情况下安全地扩展到一定程度。然而，证明计算时间随着 blob 计数的增加而增加，并且**无论谁计算证明，提议者还是另一个更强大的节点，_必须有人_ 在 4 秒区块提议的关键路径中计算证明**。这限制了我们在当前形式下使用 PeerDAS 进行扩展的程度，并且追求 64-72 个 blob 的理论极限可能有点冒险。

下表显示了基于各种 blob 计数和 CPU 线程计数的基准的**证明计算时间**估计。请注意，我们在此处使用“可用 CPU 线程”，因为节点还将在 CL 中的其他任务以及可能在同一机器上运行的 EL 和其他进程上花费周期。

| Blob 计数 \ **可用** CPU 线程 | 8 | 16 | 32 |
| --- | --- | --- | --- |
| 16 | 300ms | 150ms | 150ms |
| 32 | 600ms | 300ms | 150ms |
| 64 | 1200ms | 600ms | 300ms |
| 72 | 1350ms | 750ms | 450ms |

正如你在上面看到的，在 32 个 blob 的最佳情况下，一个强大的节点（具有 16 个可用线程）来用于提升构建仍然需要 300 毫秒来计算证明，而且它还必须将它们发布到其 mesh 对等节点。

## 可能的解决方案

有一些可能的解决方案可以允许将 blob 扩展到更高的程度：

1. **分布式 Blob 构建，允许计算所有 blob 的子集**[\[2\]](#fn2)。
2. **将证明计算卸载到交易发送者**。

选项 1 的主要缺点是复杂性以及对现有 PeerDAS 实现所需的重大更改。

**选项 2** 在 Devcon 2024 的研发研讨会以及随后的多次 CL 分组讨论中进行了讨论，所有参与者都达成了共识。作为下一步，我们希望更多人关注此提案 - 尤其是来自 EL 团队的人员，他们将参与实施其中的一些更改。

### 它是如何工作的

我们不让 CL 在区块生产期间计算单元格 KZG 证明，而是让交易发送者计算单元格证明并与交易一起发送，类似于 EIP-4844 中的做法。

```
Beacon NodeExecution ClientBlob SenderBeacon NodeExecution ClientBlob Sendercompute blob cell proofs and KZG commitmentsverify tx, cell proofs and add to blob mempoolblock production begins"extend" blobs, assemble data columns and publishsend signed EIP-4844 transactionget blobs bundlereturns blobs, commitments, and cell proofs
```

用单元格 KZG 证明替换所有层中未使用的 blob KZG 证明可能也是一个有价值的清理工作，因为它们将不再在 CL 中使用。

## 限制

最初，这并没有被广泛接受，因为它将 DAS 密码学泄露到 EL 中，并且会导致耦合，从而可能使未来的更改更加困难（例如，单元格大小缩小、编码更改等）。然而，尽管需要多层更改，但可以说这是一个更简单且必要的更改，因为它不需要大量的优化。从长远来看，如果最终我们实现了垂直分片的 blob mempool，我怀疑 EL **可能**最终会了解 DAS 密码学。

## 所需更改的高级列表

请参见 [以下附录](https://learnblockchain.cn/article/16167?both#Appendix-1-High-Level-List-of-Required-Changes)。

## 问答

> 从提案中我并不是 100% 清楚，但如果我们将证明计算从 CL 转移到 tx 发送者，那么 72 个 blob 作为新的最大值是否现实，或者是否存在不允许我们达到该值的其他限制？

根据我目前所知，我认为这是现实的 - 主要的已知瓶颈是证明计算时间和在区块提议期间传播 blob 的带宽要求。这项新提案消除了区块生产期间的证明计算瓶颈，并且到目前为止，基于测试，分布式 blob 构建在解决后者方面非常有效。

我们预计随着 blob 计数的增加，EL 带宽会增加，但与 CL 上的带宽使用量相比，它相对较小（gossip 占用大量带宽），并且我相信 CL gossip 的潜在优化可以抵消 EL 带宽的增加。一些数字在这里：[https://blog.sigmaprime.io/peerdas-distributed-blob-building.html#impact-on-node-operators](https://blog.sigmaprime.io/peerdas-distributed-blob-building.html#impact-on-node-operators)

现在，64-72 个最大 blob 仍然是一个理论限制，直到我们有一个版本可以进行测试，我只测试了最多 32 个 blob。据我所知，CL 方面没有其他已知的瓶颈，但可能的限制：

- EL 中最大 blob 为 64+ 的意外瓶颈。blob mempool 是否有任何限制？
- 分布式 Blob 构建仅适用于公共 blob 交易，而这正是当今大多数 blob 交易。我们可能需要考虑一种解决方案来覆盖私有交易，但这似乎并不是一个**直接**的障碍。

## 结论

**如果这种方法没有重大问题，那么目标是尽快在所有层面上完成规范，以便客户端团队可以开始进行实施。** 我们还需要团队来帮助推动下面列出的规范更改。

这可能是发布 PeerDAS 的第一个迭代所需的最终规范更改 - 希望在 2025 年发布。🚀

感谢阅读！

## 附录 1：所需更改的高级列表

### EIP

[更新 EIP-7594：在 blob txs 的网络包装器中包含单元格证明 #9378](https://github.com/ethereum/EIPs/pull/9378)

### EL 变更

- **RPC API**: 在 EIP-4844 交易中将 blob KZG 证明替换为单元格 KZG 证明。
- **Mempool 和数据分发**: 请参阅 Francesco 的帖子：[https://hackmd.io/@fradamt/mempool-change](https://hackmd.io/@fradamt/mempool-change)
- **Engine API**:
  - `getPayloadV5`: 更改 `BlobsBundle` 以包含单元格 KZG 证明而不是 blob KZG 证明。
  - `getBlobsV2`: 更改为返回 blob 列表和单元格 KZG 证明（而不是 blob KZG 证明）。

### CL 变更

- 更新与 EL `getBlobsBundle` 和 EL `getBlobs` 的集成
- 更新代码以组装`DataColumnSidecar`：
  - 扩展 blob
  - 使用来自 EL 的单元格证明（无需计算）
- `GetBlobSidecar` API
  - 我们不再拥有 blob KZG 证明，可能需要 v2 来返回单元格证明。

### KZG 库

更改以支持上述操作：

- tx 发送者计算单元格证明的方法：`computeProofsWithoutExtendingBlob`
- EL 验证 blob 和扩展单元格证明的方法：`verifyBlobWithExtendedProof`
- CL 扩展 blob 而无需计算证明的方法

(感谢 @Kev 的投入 🙏)

## 附录 2：分布式 Blob 构建回顾

这是一个说明 PeerDAS 中计算和带宽瓶颈的图表：

```
PeersProposer with 8 CPU coresPeersProposer with 8 CPU corest=1000ms, Produced block, and Start Compute Data Columns for 32 blobst=1900ms Computed Data Columns and Proofst=4000ms, attestation deadline, block not available yett=1000ms, Publish Beacon Blockt=1500ms, Beacon Block Sentt=1900ms, Publish Data Columns for 32 blobs (8MB to 8 mesh peers, *in parallel*)t=10000ms+, All Data Columns (64mb) sent, but too late ☠️
```

提出了分布式 blob 构建来缓解这些问题，并在网络中更强大的节点之间分配计算和数据传播工作：

```
Other nodesSupernode Peer with 32 CPU coresProposer with 8 CPU coresOther nodesSupernode Peer with 32 CPU coresProposer with 8 CPU corest=1000ms, Produced block, and Start computing Data Columns for 32 blobst=1500ms, Fetch 32 blobs from EL, start computing columnst=1800ms, Computed all data columns, block available 🎉t=1900ms Computed Data Columns, start publishing toot= ~2500ms received all columns, block available 🎉t=1000ms, Publish Beaocon Blockt=1500ms, Beacon Block Sentall supernodes publish *some* data columns
```

_注意：数字仅是基于基准和[之前使用 16 个 blob 进行的测试](https://blog.sigmaprime.io/peerdas-distributed-blob-building.html)。假设 50mbps 上传带宽，8 个核心，其中 6 个可用于证明计算，以及 8 个 mesh 对等节点。_

* * *

1. Blob 数据网络形式从 Blob 更改为 Columns，Columns 由单元格组成。

![image](https://img.learnblockchain.cn/2025/06/05/SkG7EWht1x.png)[↩︎](#fnref1)

2. 这种方法更改了数据列 gossip，以允许传输单元格和证明的子集。这将启用一种更有效、更有效的分布式 blob 构建形式，其中节点可以计算和分发单元格证明，而无需拥有所有 blob。（当前网络形式 `DataColumnSidecar` 需要所有 blob 才能计算）。[↩︎](#fnref2)

>- 原文链接： [hackmd.io/@jimmygchen/Hk...](https://hackmd.io/@jimmygchen/HkUpFliYJx)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

TL;DR（太长不看）

通过 EIP-4844，交易发送者计算 KZG 证明，并将其与 blob 交易一起发送。
在当前的 PeerDAS 设计下，验证样本需要在样本（单元格）级别进行 KZG 证明，目前这些证明是在 CL 中计算的，以避免将 DAS 密码学泄露给 EL。然而，这会造成计算瓶颈，并限制可扩展性。
提出的解决方案将此计算转移到交易发送者，因此他们为每个单元格计算 KZG 证明，而不是每个 blob，从而无需节点在区块生产窗口中计算任何 KZG 证明。

介绍

(来源: Dune)

今天我们需要更多的 blob，明天需要更多。

当前形式的 PeerDAS 能否扩展到 1D PeerDAS 的理论极限 - 最多 64 到 72 个 blob？ 简短的回答是不太可能。

(除非我们有 BPO 分叉以允许我们在分叉之间更改 blob 计数)

问题

从 PeerDAS 升级开始，blob 数据在共识层中的网络形式发生变化 - blob 数据将以 DataColumns 的形式发送，DataColumns 由 Cells 组成，每个单元格都附带一个证明[1]，节点将使用这些证明（而不是来自 Deneb 的 blob KZG 证明）来验证所有传输的单元格与 KZG 承诺。

在当前的规范中，这些单元格 KZG 证明由提议者在区块生产期间计算。计算这些证明非常昂贵，对于单个线程上的每个 blob 约为 ~150ms，但可以并行化。这已经成为一个已知的瓶颈一段时间了，并且已经有新的优化来降低这个数字，包括优化 KZG 库的性能和分布式 blob 构建。

这将允许我们在不增加完整节点硬件和带宽要求的情况下安全地扩展到一定程度。然而，证明计算时间随着 blob 计数的增加而增加，并且无论谁计算证明，提议者还是另一个更强大的节点，必须有人 在 4 秒区块提议的关键路径中计算证明。这限制了我们在当前形式下使用 PeerDAS 进行扩展的程度，并且追求 64-72 个 blob 的理论极限可能有点冒险。

下表显示了基于各种 blob 计数和 CPU 线程计数的基准的证明计算时间估计。请注意，我们在此处使用“可用 CPU 线程”，因为节点还将在 CL 中的其他任务以及可能在同一机器上运行的 EL 和其他进程上花费周期。

Blob 计数 \ 可用 CPU 线程	8	16	32
16	300ms	150ms	150ms
32	600ms	300ms	150ms
64	1200ms	600ms	300ms
72	1350ms	750ms	450ms

可能的解决方案

有一些可能的解决方案可以允许将 blob 扩展到更高的程度：

分布式 Blob 构建，允许计算所有 blob 的子集[2]。
将证明计算卸载到交易发送者。

选项 1 的主要缺点是复杂性以及对现有 PeerDAS 实现所需的重大更改。

选项 2 在 Devcon 2024 的研发研讨会以及随后的多次 CL 分组讨论中进行了讨论，所有参与者都达成了共识。作为下一步，我们希望更多人关注此提案 - 尤其是来自 EL 团队的人员，他们将参与实施其中的一些更改。

它是如何工作的

我们不让 CL 在区块生产期间计算单元格 KZG 证明，而是让交易发送者计算单元格证明并与交易一起发送，类似于 EIP-4844 中的做法。

Beacon NodeExecution ClientBlob SenderBeacon NodeExecution ClientBlob Sendercompute blob cell proofs and KZG commitmentsverify tx, cell proofs and add to blob mempoolblock production begins"extend" blobs, assemble data columns and publishsend signed EIP-4844 transactionget blobs bundlereturns blobs, commitments, and cell proofs

用单元格 KZG 证明替换所有层中未使用的 blob KZG 证明可能也是一个有价值的清理工作，因为它们将不再在 CL 中使用。

限制

所需更改的高级列表

请参见以下附录。

问答

从提案中我并不是 100% 清楚，但如果我们将证明计算从 CL 转移到 tx 发送者，那么 72 个 blob 作为新的最大值是否现实，或者是否存在不允许我们达到该值的其他限制？

我们预计随着 blob 计数的增加，EL 带宽会增加，但与 CL 上的带宽使用量相比，它相对较小（gossip 占用大量带宽），并且我相信 CL gossip 的潜在优化可以抵消 EL 带宽的增加。一些数字在这里：https://blog.sigmaprime.io/peerdas-distributed-blob-building.html#impact-on-node-operators

EL 中最大 blob 为 64+ 的意外瓶颈。blob mempool 是否有任何限制？
分布式 Blob 构建仅适用于公共 blob 交易，而这正是当今大多数 blob 交易。我们可能需要考虑一种解决方案来覆盖私有交易，但这似乎并不是一个直接的障碍。

结论

如果这种方法没有重大问题，那么目标是尽快在所有层面上完成规范，以便客户端团队可以开始进行实施。 我们还需要团队来帮助推动下面列出的规范更改。

这可能是发布 PeerDAS 的第一个迭代所需的最终规范更改 - 希望在 2025 年发布。🚀

感谢阅读！

附录 1：所需更改的高级列表

EIP

更新 EIP-7594：在 blob txs 的网络包装器中包含单元格证明 #9378

EL 变更

RPC API: 在 EIP-4844 交易中将 blob KZG 证明替换为单元格 KZG 证明。
Mempool 和数据分发: 请参阅 Francesco 的帖子：https://hackmd.io/@fradamt/mempool-change
Engine API:
- getPayloadV5: 更改 BlobsBundle 以包含单元格 KZG 证明而不是 blob KZG 证明。
- getBlobsV2: 更改为返回 blob 列表和单元格 KZG 证明（而不是 blob KZG 证明）。

CL 变更

更新与 EL getBlobsBundle 和 EL getBlobs 的集成
更新代码以组装DataColumnSidecar：
- 扩展 blob
- 使用来自 EL 的单元格证明（无需计算）
GetBlobSidecar API
- 我们不再拥有 blob KZG 证明，可能需要 v2 来返回单元格证明。

KZG 库

更改以支持上述操作：

tx 发送者计算单元格证明的方法：computeProofsWithoutExtendingBlob
EL 验证 blob 和扩展单元格证明的方法：verifyBlobWithExtendedProof
CL 扩展 blob 而无需计算证明的方法

(感谢 @Kev 的投入 🙏)

附录 2：分布式 Blob 构建回顾

这是一个说明 PeerDAS 中计算和带宽瓶颈的图表：

PeersProposer with 8 CPU coresPeersProposer with 8 CPU corest=1000ms, Produced block, and Start Compute Data Columns for 32 blobst=1900ms Computed Data Columns and Proofst=4000ms, attestation deadline, block not available yett=1000ms, Publish Beacon Blockt=1500ms, Beacon Block Sentt=1900ms, Publish Data Columns for 32 blobs (8MB to 8 mesh peers, *in parallel*)t=10000ms+, All Data Columns (64mb) sent, but too late ☠️

提出了分布式 blob 构建来缓解这些问题，并在网络中更强大的节点之间分配计算和数据传播工作：

Other nodesSupernode Peer with 32 CPU coresProposer with 8 CPU coresOther nodesSupernode Peer with 32 CPU coresProposer with 8 CPU corest=1000ms, Produced block, and Start computing Data Columns for 32 blobst=1500ms, Fetch 32 blobs from EL, start computing columnst=1800ms, Computed all data columns, block available 🎉t=1900ms Computed Data Columns, start publishing toot= ~2500ms received all columns, block available 🎉t=1000ms, Publish Beaocon Blockt=1500ms, Beacon Block Sentall supernodes publish *some* data columns

注意：数字仅是基于基准和之前使用 16 个 blob 进行的测试。假设 50mbps 上传带宽，8 个核心，其中 6 个可用于证明计算，以及 8 个 mesh 对等节点。