# Pectra 中 PeerDAS 之路
核心开发社区已经决定，PeerDAS 是尽快发布的首要任务，以便扩展以太坊的数据吞吐量。鉴于扩展吞吐量相当于提高链上 blob 数量上限，这意味着下一次硬分叉应该包含以下两个特性：
1. 部署 PeerDAS 用于数据采样
2. 提高 blob 数量
本文档进一步解释了我们如何部署 PeerDAS，并提出了两个具体建议，以减少提高 blob 数量时的“决策面”。
如果本文档的反馈是积极的，我很高兴为引擎 API 和 PeerDAS 验证器指南创建 PR，以反映所提出的更改。
## 部署 PeerDAS
在 [ACDC #134](https://github.com/ethereum/pm/issues/1050) 中决定将 PeerDAS 作为 Pectra 之上的一个特性集来实现，并使用单独的激活分叉 epoch。这种策略意味着，如果 Pectra 的其余 EIP 已经准备好发布，但我们仍然对 PeerDAS 的实现没有信心，我们可以选择轻松移除 PeerDAS。
为了说明，共识层客户端必须考虑两个 relevant 的分叉 epoch: `PECTRA_FORK_EPOCH` 和 `PEERDAS_ACTIVATION_EPOCH`。我强烈建议这两个值要么相同（意味着 PeerDAS 与 Pectra 同时上线），要么 `PEERDAS_ACTIVATION_EPOCH` 保留为最大值，而 `PECTRA_FORK_EPOCH` 设置为其主网值。拥有两个单独的 epoch 意味着开发可以并行进行，而无需围绕一个全新的分叉（例如 F/Osaka 分叉中的 PeerDAS）进行所有仪式，这会使 PeerDAS 以及其他 Pectra 特性的实施和测试复杂化。
## 部署时间表和跨层问题的延迟
上述“解耦”策略应该可以简化研发，但这确实意味着 Pectra 是否会增加 blob 数量尚不清楚。当前 blob 数量上限的实现在 CL（最大 blob 承诺数量）和 EL 层（最大 blob 数据 gas）上都有一个值。事实上，这个决策在 CL 和 EL 之间是耦合的，这意味着围绕 CL 时间表的不确定性给 EL 时间表带来了不确定性。这种不确定性是不受欢迎的，因为考虑到以太坊社区不同成员的需求，Pectra 的 EL 端的范围界定也非常复杂，因为它有很多并行特性。只要这种耦合存在，这个问题就会不断出现：仅仅为了在 CL 和 EL 客户端上更改这一个常量而进行一次完整的硬分叉。
为了解除 blob 数量周围两个协议层的耦合，我建议如下（感谢 Dankrad 提出了类似的建议）：
:::info
- 从 EL 中删除硬编码的数据 gas 限制
- 让 CL 通过 Engine API 为每个 payload 向 EL 发送数据 gas 限制（或者等价地，只需发送最大 blob 承诺数量）
:::
数据 gas 限制应该只在分叉边界处更改，所以我们可以想象 CL 每次分叉只发送一次，但是已经有先例可以从 CL 向 EL 发送数据，每次 payload 都发送（参见 EIP-4788 的父信标区块根），并且每次消息都发送数据使得验证是独立的（而不是要求 EL 跟踪每个接收到的 payload 的一些状态）。
通过这样做，EL 不再需要关心 blob gas 限制是多少，并且可以简单地遵循 CL 的指令。然后，我们可以将围绕提高 blob 数量的时间表讨论与 EL 范围讨论分开。
我认为指定此行为的最佳位置是在 Pectra Engine API 规范中。
## 关于在 Pectra 中提高 blob 数量
假设 PeerDAS 的实现在接下来的几个月里进展顺利，并且我们准备在 Pectra 中发布它，我们将需要确定如何调整最大 blob 数量。我们今天已经可以看到，[Toni 做的这个分析](https://learnblockchain.cn/article/17697#blobs-3) 表明，当前最大 blob 数量为 6 会带来更高的孤块率。可能的解释是，包含 6 个 blob 的区块已经在网络上对可用资源较低的节点（例如家里的 solo staker）造成了压力。进一步提高最大 blob 数量只会加剧这个问题，并且在以太坊扩展路线图的最终状态中，我们假设 blob 生产将由可以处理 32 MB 消息的专用节点处理。与此同时，我们不希望完全排除 home staker 参与 blob 生产，因为他们是以太坊网络的重要成员。
解决所有这些紧张关系的简单答案是让共识客户端支持一个标志，用于本地区块/blob 生产的目标。建议一个实现：
:::info
`CL_BEACON_NODE --local-block-production.maximum-blob-count N`，
其中 `N` 是信标节点在本地构建时应该包含在提议者的区块中的最大 blob 数量，无论链上最大值如何。
:::
请注意，更强大的节点（如 execution builder）可以省略此标志（使用链上最大值），或者建议一个高于 solo staker 可能更喜欢的数字。
我的理解是，对于网络上的所有节点来说，3 个 blob 的目标和 6 个 blob 的最大值都可以很好地开始，但是数据表明并非如此，因此使用 Pectra 实现此功能的时机已经成熟。在 Pectra 中这样做也有助于降低网络增加 blob 数量的风险，但代价是 solo staker 的部署稍微复杂一些（他们需要知道这个标志并在他们自己的 staking 设置中配置它）。
Josh Rudolf 提出的另一个选择是将此标志默认设置为一个足够低的数字，并让 execution builder 承担为更高的 blob 数量进行自定义的任务。此选项将复杂性从 solo staker 转移到专门的区块构建者，这更符合我们对这些节点类型的资源模型；但是，我想指出的是，默认值是很强大的，我们不希望仅仅因为构建者没有意识到这一要求而意外地阻止 blob 数量的增加。
我认为指定这种可能性的最佳位置是在共识规范中 EIP-7594 验证器指南的区块构建下。这将取决于每个共识客户端如何构建标志以及其用户的相关文档。
