本文介绍了 PeerDAS (EIP-7594) 如何通过分片 blob 数据责任的方式,在不牺牲安全性和去中心化的情况下,扩展以太坊的数据可用性,从而提高 L2 的吞吐量、降低用户费用,并增强以太坊 L1 的安全性。
这篇帖子开启了关于 PeerDAS 的多部分系列文章。在接下来的几周里,我们将发布每个主要共识层/执行层(el/cl)客户端配对的性能深度分析,展示每个堆栈在为即将到来的 Fusaka 升级做准备时的表现。
以太坊基金会最近概述了未来 12 个月的优先级:扩展 L1、扩展 blobs 和改善 UX。这很重要,因为作为以太坊主要扩展解决方案的 rollups 依赖以太坊来实现数据可用性。rollup 上保障了超过 $37B 的资金,我们下一个扩展阶段取决于充足、低成本的 blobspace 来维持用户活动。这就是 PeerDAS 的用武之地,它使以太坊能够在不牺牲安全性或去中心化的前提下处理八倍以上的数据。
如今,以太坊节点通过下载每个区块中包含的所有 blob 数据(目前最多 6 个 blobs)并保管 4,096 个 epoch(约 18 天)来处理 blob 数据可用性。虽然这确保了强大的数据可用性保证,但它施加了明确的可扩展性限制:更多的 blobs 意味着更多的存储,这需要越来越强大的节点。PeerDAS (EIP-7594) 标志着向 danksharding 方向迈出的一步,这是以太坊处理数据方式的根本转变:节点将分担 blob 保管的责任,而不是下载所有 blob 数据。
通过利用经过实战考验的网络组件构建现有的基础设施和带宽需求,PeerDAS 使以太坊能够扩展到每个区块 至少 48 个 blob 目标,从而将 blob 容量提高 8 倍,并将吞吐量从 ~220 提高到 ~3,500 UOPS(每秒用户操作数),而不会影响以太坊的安全保证。这意味着更低的成本、更好的用户体验和更强大的生态系统。此外,L2 活动的增加将转化为 L1 上更多的总费用,通过提高验证者收入和加强网络安全来增强以太坊的安全模型。
简而言之,通过 PeerDAS 扩展 L2 可以加强以太坊的 L1。
在本文中,我们将探讨 PeerDAS 的工作原理以及它如何影响不同的生态系统利益相关者——从节点运营商和 rollups 到应用程序开发人员和用户。我们还将分享 OP Labs 如何与 Sunnyside Labs、Base 和 Soneium 合作,以加速在今年晚些时候推出的 Fusaka 升级中启动 PeerDAS。
随着 Pectra 现在上线,每个区块的 blob 目标为 6,blob 限制为 9。每个 blob 最多可以容纳 128KB 的数据。如果只考虑 blob 数据有效载荷(不包括诸如 kzg_commitment 或 kzg_proof 之类的额外数据),由于所有节点都保管所有 blobs,因此所有节点都需要存储 128 kB x 6 = 768 kB 的数据每个区块。
节点需要保管每个区块中包含的所有 blob 数据 4,096 个 epoch(约 18 天)
在本节中,我们将从高层次讨论 PeerDAS 的工作原理。要深入了解技术架构,我们强烈建议阅读 这篇文章。Manu 的 PeerDAS from scratch 也是一篇很棒的读物!
借助 PeerDAS,blob 大小使用 纠删码 增加一倍,即我们将 blobs 分成 64 列并执行纠删码以扩展到 128 列。每个完整节点都会下载并验证一小部分随机分配的数据。在网络级别(在撰写本文时,超过 9,600 个验证完整节点)。这提供了非常高的确定性,即完整数据集可用。通过抽样而不是完全下载 blobs,以太坊可以在不增加节点存储和带宽需求的情况下实现 blob 容量的八倍提升。
大多数验证节点将需要保管和服务 8 列(稍后会详细介绍)。如果只考虑 blob 数据有效载荷(不包括诸如 kzg_commitment 或 kzg_proof 之类的其他数据),我们可以定义以下内容:
每个节点保管 8 个数据列
每个区块目标 48 个 blobs
每个单元格容纳 2 kB 的数据
这意味着所有验证节点都需要存储 8 x 48 x 2 kB = 768 kB 的 blob 数据每个区块(你会注意到这与当前 6 个 blobs/区块的存储要求相同!)
我们将 blobs 分成 64 列并执行纠删码以扩展到 128 列。
通过在整个网络中分配责任并依靠抽样而不是完全保管,以太坊可以有效地扩展,而不会牺牲去中心化或安全性。
执行层和共识层客户端都将看到更新以支持 PeerDAS。这些包括对 blob 流言、子网抽样、验证者保管和单元格验证逻辑的更改。
节点运营商: 你的节点不会看到提取整个 blobs,而是会订阅指定数据切片的流言子网并响应来自对等方的抽样请求。你将配置保管参数并部署更新的软件,但日常硬件要求仍在你现有的容量范围内。更高的 blob 吞吐量也将导致更高的费用支出(更多的 blobs 意味着更多的 blob gas 和承诺交易,这意味着验证者运营商的更多费用/收入)。
需要注意的几点:
非验证节点将处理至少 4 个数据列
至少有一个附加验证器的节点处理至少 8 个数据列
对于每额外质押的 32 ETH,节点存储一个额外的数据列
质押 ≥ 1,824 ETH(57 个验证器)的节点处理至少 64 列,从而可以重建整个集合
质押 ≥ 3,872 ETH(121 个验证器)的节点必须处理所有 128 列,并且称为超级节点
Solo stakers: PeerDAS 确保了 solo 质押仍然可访问,从而使 solo stakers 能够使用经济实惠的家庭设置或云 VM 来保护以太坊。你的节点只会下载每个 blob 数据的一小部分,执行轻量级的证明检查,从而使 CPU 和带宽要求保持在当前建议范围内。
Rollups: Rollups 立即从 PeerDAS 中受益。在 48 个 blob 目标下,rollups 获得了近 3,300 个 UOPS 的额外数据可用性容量。这使 rollups 能够提高 gas 吞吐量,降低用户的费用,并自信地探索更新、gas 密集型应用程序。
最终用户和应用程序开发人员: 较低的数据可用性成本直接转化为最终用户费用的降低和用户体验的改善。应用程序开发人员可以依靠其 rollups 中更高的 gas 吞吐量,从而实现更快、响应更快的去中心化应用程序。
Optimism 仍然坚定地致力于以太坊的长期成功。达到 48 个 blob 目标并非易事,但整个生态系统的团队一直在为此努力。在接下来的几周内,我们计划发布来自 Sunnyside Labs 的 PeerDAS devnets 的详细见解,展示性能基准、进展以及我们在接近雄心勃勃的 48 个 blob 目标时面临的关键挑战。
请继续关注 - 我们正在一起将以太坊带给每个人。
我们正在招聘!如果你热衷于扩展以太坊、推进 Superchain 以及为世界构建开放、去中心化的基础设施,请查看我们的 开放职位。我们很乐意收到你的来信。
- 原文链接: optimism.io/blog/peerdas...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!