# V 神关于 EIP-4844 Danksharding 的 Q&A By [0Paradigm](https://paragraph.com/@0paradigm) · 2022-03-20 --- [https://notes.ethereum.org/@vbuterin/proto\_danksharding\_faq](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) 什么是 Danksharding？ ----------------- Danksharding 是为以太坊提出的新分片设计，与之前的设计相比，它引入了一些显着的简化。 自 2020 年以来所有最近的以太坊分片提案（包括 Danksharding 和 pre-Danksharding）与大多数非以太坊分片提案之间的主要区别在于以太坊\*\*[以汇总为中心的路线图](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)\*\*（另请参见：[\[1\]](https://polynya.medium.com/understanding-ethereums-rollup-centric-roadmap-1c60d30c060f) [\[2\]](https://vitalik.ca/general/2019/12/26/mvb.html) [\[3\]](https://vitalik.ca/general/2021/01/05/rollup.html)）：而不是为_交易_提供更多空间，以太坊分片为_数据_块提供更多空间，以太坊协议本身并不试图解释。验证 blob 只需要检查 blob 是否\*[可用](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding)\*- 是否可以从网络下载。这些 blob 中的数据空间预计将由支持高吞吐量事务[的第 2 层汇总协议使用。](https://vitalik.ca/general/2021/01/05/rollup.html) [**Danksharding**](https://notes.ethereum.org/@dankrad/new_sharding)**引入的主要创新（另见：**[**\[1\]**](https://polynya.medium.com/danksharding-36dc0c8067fe) [**\[2\]**](https://www.youtube.com/watch?v=e9oudTr5BE4) [**\[3\]**](https://github.com/ethereum/consensus-specs/pull/2792)**）是合并的费用市场**：不是有固定数量的分片，每个分片都有不同的块和不同的块提议者，在 Danksharding 中只有一个提议者选择进入该槽的所有交易和所有数据。 为了避免这种设计对验证者的系统要求很高，我们引入了**提议者/构建者分离（PBS）**（另见：[\[1\]](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) [\[2\]](https://ethresear.ch/t/two-slot-proposer-builder-separation/10980)）：一个称为**块构建**者的特殊类别的参与者竞标选择内容的权利slot，提议者只需要选择出价最高的有效标头即可。只有块生成器需要处理整个块（即使在那里，也可以使用第三方去中心化预言机协议来实现分布式块生成器）；所有其他验证者和用户都可以通过\*\*[数据可用性采样](https://hackmd.io/@vbuterin/sharding_proposal)\*_非常有效地_验证\*区块（请记住：区块的“大”部分只是数据）。 什么是 proto-danksharding（又名 EIP-4844）？ ------------------------------------ Proto-danksharding（又名[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)）是一个提议，用于实现构成完整 Danksharding 规范的大部分逻辑和“脚手架”（例如交易格式、验证规则），但尚未实际实现任何分片。在 proto-danksharding 实现中，所有验证者和用户仍然必须直接验证完整数据的可用性。 proto-danksharding 引入的主要特征是新的交易类型，我们称之为**携带 blob 的交易**。携带 blob 的事务类似于常规事务，不同之处在于它还携带一个称为**blob**的额外数据。Blob 非常大（~125 kB），并且比类似数量的调用数据便宜得多。但是，EVM 执行无法访问 blob 数据；EVM 只能查看对 blob 的承诺。 因为验证者和客户端仍然需要下载完整的 blob 内容，所以 proto-danksharding 中的数据带宽目标为每个插槽 1 MB，而不是完整的 16 MB。然而，由于这些数据没有与现有以太坊交易的 gas 使用量竞争，因此仍然有很大的可扩展性收益。 为什么向每个人都必须下载的块添加 1 MB 数据是可以的，而不是让 --------------------------------- **这与平均负载**和**最坏情况负载**之间的差异有关。今天，我们已经遇到了平均块大小[约为 90 kB](https://etherscan.io/chart/blocksize)的情况，但理论上可能的最大块大小（如果一个块中的_所有_30M 气体都用于 calldata）约为 1.8 MB。以太坊网络过去处理的区块接近最大值。但是，如果我们简单地将 calldata gas 成本降低 10 倍，那么尽管_平均_块大小会增加到仍然可以接受的水平，但_最坏的情况_会变成 18 MB，这对于以太坊网络来说实在是太多了。 当前的 gas 定价方案无法将这两个因素分开：平均负载与最坏情况负载之间的比率取决于用户在 calldata 与其他资源上花费多少 gas 的选择，这意味着 gas 价格必须是根据最坏情况的可能性设置，导致平均负载不必要地低于系统可以处理的负载。但是\*\*，如果我们改变 gas 定价以更明确地创建一个[多维费用市场](https://ethresear.ch/t/multidimensional-eip-1559/11651)，我们可以避免平均情况/最坏情况负载不匹配\*\*，并在每个区块中包含接近我们可以安全处理的最大数据量的数据。Proto-danksharding 和[EIP-4488](https://eips.ethereum.org/EIPS/eip-4488)正是这样做的两个提议。 ![](https://storage.googleapis.com/papyrus_images/9c900a9f0de8e3378f5ec54285cd3233cd83d4fa94535795e0f2ae220a749369.png) proto-danksharding ------------------ \*\*[EIP-4488](https://eips.ethereum.org/EIPS/eip-4488)\*\*是解决相同平均情况/最坏情况负载不匹配问题的较早且更简单的尝试。EIP-4488使用两个简单的规则来做到这一点： * Calldata gas 成本从每字节 16 gas 降低到每字节 3 gas * 每个块 1 MB 的限制加上每个事务额外的 300 字节（理论最大值：~1.4 MB） 硬限制是确保平均情况负载的较大增加不会导致最坏情况负载增加的最简单方法。天然气成本的降低将大大增加汇总使用，可能会将平均块大小增加到数百 KB，但硬限制将直接阻止包含 10 MB 的单个块的最坏情况可能性。事实上，最坏情况下的块大小会比现在低（1.4 MB 对 1.8 MB）_。_ **Proto-danksharding**而是创建了一个单独的事务类型，可以在大型固定大小的 blob 中保存更便宜的数据，并且每个块可以包含多少 blob。这些 blob 无法从 EVM 访问（只有对 blob 的承诺），并且 blob 由共识层（信标链）而不是执行层存储。 **EIP-4488 和 proto-danksharding 之间的主要实际区别在于 EIP-4488 试图最小化今天所需的更改，而 proto-danksharding 今天进行了大量更改，因此将来升级到完全分片需要很少的更改**. 尽管实现全分片（使用数据可用性采样等）是一项复杂的任务，并且在原型 danksharding 之后仍然是一项复杂的任务，但这种复杂性包含在共识层中。一旦 proto-danksharding 推出，执行层客户端团队、汇总开发人员和用户不需要做进一步的工作来完成向全分片的过渡。 请注意，两者之间的选择_不是_非此即彼的：我们可以很快实现 EIP-4488，然后在半年后使用 proto-danksharding 跟进它。 proto-danksharding 实现了完整 danksharding 的哪些部分，还有哪些需要实现？ ----------------------------------------------------- 引用 EIP-4844： > 本 EIP 中已经完成的工作包括： > > * 一种新的交易类型，格式完全相同，需要存在于“全分片”中 > > * 全分片所需的所有执行层_逻辑_ > > * _全分片所需的所有_执行/共识交叉验证逻辑 > > * 验证和数据可用性采样 blob之间的层分离`BeaconBlock` > > * 全分片所需的大部分逻辑`BeaconBlock` > > * 用于 blob 的自我调整的独立 gasprice。 > > > 完全分片还有待完成的工作包括： > > * 共识层中的低度扩展`blob_kzgs`以允许 2D 采样 > > * 数据可用性抽样的实际实现 > > * PBS（提议者/建造者分离），以避免要求单个验证者在一个插槽中处理 32 MB 的数据 > > * 每个验证者的托管证明或类似的协议内要求，以验证每个块中分片数据的特定部分 > 请注意，所有剩余工作都是共识层更改，不需要执行客户端团队、用户或汇总开发人员的任何额外工作。 所有这些非常大的块导致的 ------------ EIP-4488 和 proto-danksharding 都导致每个插槽（12 秒）的长期最大使用量约为 1 MB。这相当于每年大约 2.5 TB，远高于以太坊今天所需的增长率。 **在 EIP-4488 的情况下，解决此问题需要历史记录到期 (** [**EIP-4444**](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) **)**，其中不再要求客户端存储超过某个时间段的历史记录（已提出从 1 个月到 1 年的持续时间）。 **在 proto-danksharding 的情况下**，无论是否实施 EIP-4444，共识层都可以实施单独的逻辑以在一段时间（例如 30 天）后自动删除 blob 数据。但是，无论采用何种短期数据扩展解决方案，都强烈建议尽快实施 EIP-4444。 这两种策略都将共识客户端的额外磁盘负载限制在最多几百 GB。**从长远来看，采用一些历史过期机制本质上是强制性的**：全分片每年会增加大约 40 TB 的历史 blob 数据，因此用户实际上只能将其中的一小部分存储一段时间。因此，值得尽早设定对此的期望。 如果数据在 30 天后被删除，用户将如何访问旧 Blob？ ----------------------------- **以太坊共识协议的目的不是保证所有历史数据的永久存储。相反，目的是提供一个高度安全的实时公告板，并为其他去中心化协议做更长期的存储留出空间**。公告板的存在是为了确保在公告板上发布的数据可用时间足够长，以便任何想要该数据的用户或任何备份数据的长期协议都有足够的时间来获取数据并将其导入到他们的其他应用程序或协议中。 一般来说，长期历史存储很容易。虽然每年 2.5 TB 对常规节点的需求太大，但对于专用用户来说非常易于管理：您可以以[每 TB 约 20 美元](https://www.amazon.com/Seagate-IronWolf-16TB-Internal-Drive/dp/B07SGGWYC1)的价格购买非常大的硬盘驱动器，这完全可以满足爱好者的需求。与具有 N/2-of-N[信任模型](https://vitalik.ca/general/2020/08/20/trust.html)的共识不同，历史存储具有 1-of-N 信任模型：您只需要其中一个数据存储者是诚实的。因此，每条历史数据只需要存储数百次，而不是完整的数千个正在做实时共识验证的节点。 存储完整历史记录并使其易于访问的一些实用方法包括： * \*\*特定于应用程序的协议（例如汇总）\*_可以要求_其\*节点存储与其应用程序相关的历史记录部分。丢失的历史数据对协议没有风险，只会对单个应用程序造成风险，因此应用程序承担存储与自己相关的数据的负担是有意义的。 * **在BitTorrent**中存储历史数据，例如。每天自动生成和分发一个 7 GB 的文件，其中包含来自块的 blob 数据。 * **以太坊**[**门户网络**](https://www.ethportal.net/)（目前正在开发中）可以很容易地扩展到存储历史。 * **区块浏览器、API 提供者和其他数据服务**可能会存储完整的历史记录。 * **个人爱好者和从事数据分析的学者**可能会存储完整的历史记录。在后一种情况下，将历史存储在本地为它们提供了重要的价值，因为它使直接对其进行计算变得更加容易。 * [**TheGraph**](https://thegraph.com/en/)**等第三方索引协议**可能会存储完整的历史记录。 在更高级别的历史存储（例如每年 500 TB）下，某些数据被遗忘的风险会变得更高（此外，数据可用性验证系统会变得更加紧张）。这可能是分片区块链可扩展性的真正极限。然而，目前所有提出的参数都远未达到这一点。 （未完待续） 原文链接： [https://notes.ethereum.org/@vbuterin/proto\_danksharding\_faq](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) --- *Originally published on [0Paradigm](https://paragraph.com/@0paradigm/v-eip-4844-danksharding-q-a)*