PeerDAS如何降低以太坊节点负担
PeerDAS（点对点数据可用性采样）降低节点负担的核心机制是"分而治之"：它不再要求每个节点下载全部 blob 数据，而是将数据切分成小块，让每个节点只随机存储和验证一小部分，通过密码学手段保证整体数据的可恢复性。这样一来，在总数据量大幅增加的同时，单个节点的存储和带宽需求保持不变。
这个设计直接回应了以太坊扩容的一个关键瓶颈：如果不改变数据可用性的验证方式，L2 交易量每增加一倍，运行节点的资源需求也会相应增加，最终只有少数数据中心能负担得起运行节点的成本，损害网络的去中心化。
前置条件
你对以太坊的"Blob"有基本概念（Dencun 升级引入的专门用于 L2 数据存储的临时数据类型）。
你了解当前（Pectra 升级后）每个区块最多包含 9 个 Blob，目标值为 6 个。
你关注的是 PeerDAS 上线后对普通节点运营者的影响。
步骤1：理解 PeerDAS 如何重新分配任务
在 PeerDAS 之前，每个节点都需要下载和存储一个区块内包含的所有 blob 数据。这导致节点负担会随着 blob 数量的增加而成比例增长。
PeerDAS 引入了"数据可用性采样"（DAS），把验证任务拆解：
切割与冗余：将一个 blob 的数据通过"擦除编码"扩展一倍。把扩展后的数据切分成 128 个"列"（columns），只要拿到其中任意 64 列就能恢复整个 blob。
随机分配：每个节点根据其节点 ID，被随机分配去存储和验证其中的一小部分列（通常为 8 列）。
验证可用性：一个节点不需要下载全部数据，它只需要随机向网络中的其他节点请求几个列的数据片段，通过密码学证明（KZG 承诺）来确认这些片段是真实的。只要大多数节点都能成功采样到各自的片段，就可以高概率地确认整个数据集是完整可用的。
简单来说，这就像一个巨大的拼图，每个人只负责保管和检查几块碎片，并通过相互核对来确认整幅画是完整的，而不需要任何一个人拥有所有碎片。
步骤2：计算节点负担的实际变化
通过上面的机制，PeerDAS 实现了"扩容不增负"的效果。以下是在不同目标 blob 数量下的节点存储需求对比：
| 网络状态 | 每区块目标 Blob 数 | 节点数据存储量（约） | 备注 |
|---|---|---|---|
| Pectra 升级（当前） | 6 个 | 768 KB / 区块 | 每个节点需存储全部 blob 数据。 |
| Fusaka + PeerDAS | 6 → 48 个（逐步提升） | 768 KB / 区块 | 每个节点只存储 8 列数据，总存储量与升级前持平。 |
| Fusaka + PeerDAS（初期） | 14 个（2026年1月7日目标） | 约 32 GB | 对有1-8个验证者的节点而言，比当前的约100GB 存储需求更低。 |
核心结论：即使未来 blob 目标增加到 48 个，单个节点的存储和带宽需求不会成倍增长，基本维持在升级前的水平。这为未来可能达到的 48 个 blob 目标（数据吞吐量约为目前的 8 倍）奠定了基础。
步骤3：了解不同角色的具体要求
PeerDAS 对不同类型的节点提出了差异化要求：
普通全节点（无验证者） ：只需存储和托管 4 个数据列，并额外采样 4 个列。需求最低。
验证者节点（有质押 ETH） ：至少需要存储 8 个数据列。每多质押 32 ETH（即多一个验证者），需要额外存储 1 个数据列，最多到 128 列。
"超级节点"（Supernode） ：质押超过 3,872 ETH 或主动开启此模式的节点，需要存储全部 128 个数据列。这类节点可以更快地响应 blob 查询，并帮助网络修复数据缺口。
常见失败原因
误以为"采样"意味着节点不需要任何数据了。
这是一个普遍的误解。PeerDAS 的"采样"并不是让节点完全不管数据，而是把"验证职责"从存储全部数据变成了"存储一小部分数据 + 从网络中采样其他部分"。节点仍然需要承担存储和带宽开销，只是这个开销被控制在了固定且较低的水平，不会随着网络扩容而上升。它牺牲了数据的"全量复制"，换来了更高效的"分布式验证"。
风险提醒
Fusaka 升级后，普通节点将无法提供完整的 Blob 数据：如果你运行的节点需要提供完整的 blob 数据（例如为 L2 提供服务），就必须开启半超级节点或超级节点模式，这会显著增加存储和带宽需求。
"超级节点"的中心化风险：虽然减少了普通节点的负担，但新机制催生了存储全量数据的"超级节点"。如果这类节点数量过少，可能会影响数据修复的效率。
分叉选择攻击：理论上，攻击者可以利用数据采样阶段的不确定性来发动"提前重组"攻击，通过让部分验证者认为数据可用来影响最终共识。协议设计已考虑这一风险，开发者正在通过调整参数来降低安全风险。
如何确认 PeerDAS 正常运行
普通节点运营者不需要主动操作。升级完成后，你可以通过以下方式确认：
你的节点客户端（如 Lighthouse、Teku）更新至支持 Fusaka 的版本，启动时没有报错。
在区块浏览器或客户端日志中，查看"数据列"相关的信息。如果你没有开启"超级节点"模式，你的节点将不会同步完整的 blob 数据，但会正常参与数据可用性采样过程，并且不会出现资源耗尽的情况。
