以太坊的下一个里程碑式升级？ Buterin 解释了 EIP-4844 是什么

以太坊创始人 Vitalik Buterin 最近回答了有关 Proto-danksharding（又名 EIP-4844））的问题。Danksharding 为以太坊提出了一种新的分片设计，这项技术能带来什么？

什么是 Danksharding？

Danksharding 是为以太坊提出的一种新的分片设计，与以前的设计相比，它引入了一些显着的简化。

自 2020 年以来所有最近的以太坊分片提案（包括 Danksharding 和更早的 Danksharding）与大多数非以太坊分片提案的主要区别在于，以太坊是以 Rollup 为中心的路线图：以太坊分片不为交易提供更多空间，而是为数据提供更多空间，以太坊协议本身并不试图解释。验证 blob 只是检查 blob 是否可用，即是否可以从网络下载。数据空间预计将由支持高吞吐量事务的第 2 层（Layer2）Rollup 协议）使用。

Danksharding 引入的主要创新是整合费市场：不再是固定数量的分片，每个分片有不同的区块和不同的区块提议者。在 Danksharding 中，只有一个提议者选择所有交易和进入槽的所有数据。

为了避免这种设计对验证器提出了很高的系统要求，我们引入了提议者/构建者分离（PBS）：一种称为块构建者的特殊参与者类别竞标选择插槽的权利，并且提议者只需选择最高出价有效头。只有出块方需要处理整个区块（这里也可以使用第三方去中心化预言机协议来实现分布式出块方）；所有其他验证者和用户都可以通过数据可用性非常有效地进行抽样（请记住：块的“大”部分只是数据）。

什么是 proto-danksharding（又名 EIP-4844）？

Proto-danksharding（又名 EIP-4844） 是一个以太坊改进提案（EIP），它实现了构成完整 Danksharding 规范的大部分逻辑和“脚手架”（例如交易格式、验证规则）） ，但实际上还没有实现分片。在 proto-danksharding 实现中，所有验证者和用户仍然必须直接验证完整数据的可用性。

proto-danksharding 引入的主要特性是一种新的事务类型，我们称之为 Of 是一个带有 blob 的事务。带有 blob 的事务类似于常规事务，不同之处在于它还携带称为 blob 的额外数据。 Blob 非常大（~125 kB）并且比类似数量的调用数据便宜得多。但是，EVM 执行无法访问 blob 数据； EVM 只能查看对 blob 的承诺。

因为验证器和客户端仍然需要下载完整的 blob 内容以太坊合并，所以 proto-danksharding 中的数据带宽目标是每个插槽 1 MB，而不是完整的 16 MB。但是，由于这些数据不会与现有以太坊交易的 gas 使用量竞争，因此仍有很大的可扩展性优势。

为什么可以将 1 MB 的数据添加到每个人都必须下载的块中，而不是让 calldata 便宜 10 倍？

这与平均负载和最坏情况负载之间的差异有关。今天，我们的平均块大小约为 90 kB，但理论上可能的最大块大小（如果块中所有 30M 的气体都用于调用数据）约为 1.8 MB。以太坊网络过去处理的区块接近最大值。然而，如果我们简单地将 calldata gas 成本降低 10 倍，那么当平均块大小增加到仍然可以接受的水平时，最坏的情况会变成 18 MB，这对于以太坊网络来说太多了。

当前的 gas 定价方案无法将这两个因素分开：平均负载和最坏情况负载之间的比率取决于用户选择在 calldata 与其他资源上花费多少 gas，这意味着 gas 价格必须基于最坏情况的概率，导致平均负载不必要地低于系统可以处理的水平。但是，如果我们更改 gas 定价以更明确地创建多维费用市场，我们可以避免平均情况/最坏情况负载不匹配，并在每个块中包含接近我们可以安全处理的最大数据量的数据。 Proto-danksharding 和 EIP-4488 是这样做的两个提议。

proto-danksharding 与 EIP-4488 相比如何？

EIP-4488 是解决相同平均情况/最坏情况负载不匹配问题的较早且更简单的尝试。 EIP-4488 使用两个简单的规则来做到这一点：

硬性限制是确保平均情况负载大幅增加不会导致最坏情况负载增加的最简单方法。 gas 成本的降低将大大增加 rollup 的使用，潜在地将平均块大小增加到数百 KB，但硬限制将直接防止单个块包含 10 MB 的最坏情况的可能性。事实上，最坏情况下的块大小会比现在更小（1.4 MB vs 1.8 MB）。

Proto-danksharding 而是创建了一个单独的事务类型，可以在大型固定大小的 blob 中保存更便宜的数据，并限制每个块可以包含多少 blob。这些 blob 无法从 EVM 访问（仅提交到 blob），并且 blob 由共识层（信标链）而不是执行层存储。

EIP-4488 和 proto-danksharding 的主要实际区别在于 EIP-4488 试图将今天所需的更改最小化，而 proto-danksharding 今天有很多更改，因此将来升级到完全分片必需的。尽管实现全分片（使用数据可用性采样等）是一项复杂的任务，并且在 proto-danksharding 之后仍然是一项复杂的任务，但这种复杂性包含在共识层中。 proto-danksharding 推出后，执行层客户端团队、汇总开发人员和用户无需进一步工作即可完成向全分片的过渡。

请注意，两者之间的选择不是任何一个：我们可以尽快实现 EIP-4488，然后在半年后跟进 proto-danksharding。

proto-danksharding 实现了完整 danksharding 的哪些部分，还有哪些需要实现？

引用 EIP-4844：

在这个 EIP 中已经完成的工作包括： 一种新的交易类型，格式完全相同，需要存在于“完整分片”中。全分片所需的所有执行层逻辑。全分片所需的所有执行/共识交叉验证逻辑。 BeaconBlock 验证和数据可用性采样 blob 之间的层分离。完全分片所需的大部分 BeaconBlock 逻辑。 Blob 的自调整独立 gasprice。实现完全分片尚待完成的工作包括： 共识层中 blob_kzgs 的低缩放以允许 2D 采样。数据可用性采样的实际实现，PBS（Proposer/Builder Separation）以避免需要单个验证器在单个插槽中处理 32 MB 的数据。每个验证者的托管证明或类似的协议内要求，以验证每个块中分片数据的特定部分。

请注意，所有剩余工作都是共识层更改，不需要客户团队、用户或汇总开发人员进行任何额外工作。

如果所有这些非常大的块都增加了磁盘空间需求怎么办？

EIP-4488 和 proto-danksharding 都导致每个套接字的长期最大使用量约为 1 MB（12 秒）。这相当于每年大约 2.5 TB，远高于以太坊今天所需的增长率。

在 EIP-4488 的情况下，解决这个问题需要一个历史过期方案 (EIP-4444‌)，其中不再需要客户端存储超过特定时间段的历史记录（建议从 1 个月到 1 年的持续时间） .

在 proto-danksharding 的情况下，无论是否实现 EIP-4444，共识层都可以实现单独的逻辑以在一段时间（例如 30 天）后自动删除 blob 数据。但是，无论短期数据扩展方案如何，强烈建议尽快实施 EIP-4444。

这两种策略都将共识客户端的额外磁盘负载限制为最大数百 GB。从长远来看以太坊合并，拥有一些历史过期机制本质上是强制性的：一个完整​​的分片每年会增加大约 40 TB 的历史 blob 数据，因此用户实际上只能暂时存储其中的一小部分。因此，值得尽早为此设定期望。

如果数据在 30 天后被删除，用户将如何访问旧 Blob？

以太坊共识协议的目的不是保证所有历史数据的永久存储。相反，其目的是提供一个高度安全的实时公告板，并为其他去中心化协议留出空间以进行长期存储。公告板的存在是为了确保发布在公告板上的数据可用足够长的时间，以便任何想要该数据或任何长期协议备份它的用户有足够的时间获取数据并将其导入到他们的另一个应用程序或协议。

一般来说，长期历史存储很容易。虽然2.每年 5 TB 对于普通节点来说要求过高，但对于专用用户来说非常易于管理：您可以以每 TB 约 20 美元的价格购买非常大的硬盘驱动器，这对于爱好用户来说已经绰绰有余了'需要。与具有 N/2-of-N 信任模型的共识不同，历史存储具有 1-of-N 信任模型：您只需要其中一个数据存储即可。因此，每条历史数据只需要存储数百次，而不需要完整的数千个节点进行实时共识验证。

存储完整历史记录并使其易于访问的一些实用方法包括：

在更高级别的历史存储（例如每年 500 TB）下，某些数据被遗忘的风险会变得更高（此外，数据可用性验证系统会变得更加紧张）。这可能是分片区块链可扩展性的真正限制。但是，目前所有提出的参数都离这一点很远。

blob数据的格式是什么，如何提交？

一个blob是4096个字段元素的向量，范围内的数字：

一个 blob 在数学上被认为是在有限的数字域上表示具有上述度数的模

对 blob 的承诺是 KZG 承诺的多项式的哈希。然而，从实现的角度来看，关注多项式的数学细节并不重要。相反，将只有一个椭圆曲线点的向量（基于拉格朗日的合理设置），而 KZG 对 blob 的承诺将只是一个线性组合。引用 EIP-4844 的代码：

def blob_to_kzg(blob: Vector[BLSFieldElement, 4096]) -> KZGCommitment: computed_kzg = bls.Z1 for value, point_kzg in zip(tx.blob, KZG_SETUP_LAGRANGE): assert value

BLS_MODULUS 是上面的模数，KZG_SETUP_LAGRANGE 是椭圆曲线点的向量，是基于拉格朗日的可信设置。对于实现者来说，现在可以将其简单地视为一个黑盒专用散列函数。

为什么直接使用 KZG 的哈希而不是 KZG？

EIP-4844 不使用 KZG 直接表示 blob，而是使用版本化哈希：单个 0x01 字节（表示此版本）后跟 KZG 的 SHA256 哈希的最后 31 个字节。

这样做是为了 EVM 兼容性和未来的兼容性：KZG 承诺为 48 字节，而 EVM 更自然地使用 32 字节值，如果我们从 KZG 切换到其他东西（例如，出于量子抵抗的原因），KZG promise 可以继续为 32 字节。

proto-danksharding 中引入的两种预编译是什么？

Proto-danksharding 引入了两种预编译：blob 验证预编译和点评估预编译。

Blob 验证预编译是不言自明的：它将版本化哈希和 Blob 作为输入，并验证提供的版本化哈希实际上是 Blob 的有效版本化哈希。此预编译旨在供 Optimistic Rollup 使用。引用 EIP-4844：

Optimistic Rollup 只需要在提交欺诈证明时实际提供底层数据。欺诈证明提交功能将要求欺诈 blob 的全部内容作为 calldata 的一部分提交。它将使用 blob 验证来根据之前提交的版本化哈希验证数据，然后像现在一样对该数据执行欺诈证明验证。

点评估预编译将版本化哈希、x 坐标、y 坐标和证明（blob 的 KZG 承诺和 KZG 评估证明）作为输入。它验证证明以检查 P(x) = y，其中 P 是具有给定版本化哈希的 blob 表示的多项式。此预编译旨在供 ZK Rollup 使用。引用 EIP-4844：

ZK rollup 将为其事务或状态增量数据提供两个承诺：Blob 中的 KZG 和一些使用 ZK rollup 内部使用的任何证明系统的承诺。他们将使用等价协议的 Promise 证明，使用点评估预编译，来证明 kzg（协议保证指向可用数据）和 ZK rollup 自己的 Promise 引用相同的数据。

请注意，大多数主要的 Optimistic Rollup 设计都使用多轮欺诈预防方案，最后一轮只需要少量数据。所以可以想象，Optimistic Rollup 也可以使用点求值预编译代替 Blob 验证预编译，这样会更便宜。

KZG 可信设置是什么样的？

见：

powers-of-tau 可信设置如何工作的一般描述

所有重要的可信设置相关计算的示例实现

p>

特别是在我们的例子中，当前的计划是并行运行四种尺寸 (n1=4096,n2=16）,(n1=8192,n2=16）, (n1=16834 ,n2=16） 和 (n1=32768,n2=16） 仪式（具有不同的秘密）。理论上只需要第一个，但运行更大的尺寸，提高未来的适用性允许我们增加 blob 大小。我们不能只是有一个更大的设置，因为我们希望能够对可以有效提交的多项式次数有一个硬限制，它等于 blob 大小。

一种可能的实用方法是从 Filecoin 设置开始，然后运行一个仪式来扩展它。包括浏览器实现在内的多种实现将允许多人参与。

如果没有受信任的设置，我们就不能使用其他一些承诺方案吗？

不幸的是，使用 KZG 以外的任何东西（如 IPA 或 SHA256） 会使分片路线图变得不那么复杂）更加困难。这有几个原因：

因此，不幸的是，使用 KZG 以外的任何东西所带来的功能损失和增加的复杂性远远超过了 KZG 本身的风险。另外，任何与 KZG 相关的风险都包括在内：一次 KZG 故障只会影响 Rollup 和其他依赖 blob 数据的应用程序，不会影响系统的其余部分。

KZG 有多“复杂”和“新”？

KZG 承诺是在 2010 年的一篇论文中介绍的‌，并且自 2019 年以来已广泛用于 PLONK 类型的 ZK-SNARK 协议。但是，KZG 承诺的基础数学是椭圆 曲线运算的基础数学之上的相对简单的算术和配对。

使用的具体曲线是 BLS12-381‌，它是 Barreto-Lynn-Scott 在 2002 年发明的。椭圆曲线配对是验证 KZG 承诺所需的数学非常复杂，但它们是在 1940 年代发明并应用于密码学自 1990 年代以来。到 2001 年，提出了许多使用配对的加密算法。

从实现复杂度的角度来看，KZG 并不比 IPA 更难实现：计算 promise 的函数（见上文）与 IPA 中的完全相同，只是使用了一组不同的椭圆曲线点常数。点验证预编译更复杂，因为它涉及配对 Evaluates，但数学与 EIP-2537（BLS12-381 预编译）实现中已经完成的相同，并且与 bn128 配对预编译非常相似（另见：优化的 Python执行）。所以实现KZG验证不需要复杂的“新工作”

proto-danksharding 实现有哪些不同的软件部分？

有四个主要组成部分：

1.执行层共识变更（详见 EIP）：

2.Consensus Layer 共识更改（请参阅 repo 中的此文件夹）：

3.内存池

4.区块构造逻辑

请注意，对于最小的实现，我们根本不需要内存池（我们可以依赖第二层交易捆绑市场），我们只需要一个客户端来实现块构建逻辑。只有执行层和共识层的共识更改需要广泛的共识测试，并且相对轻量级。在这种最小实现和所有客户端都支持块生产和内存池的“完整”部署之间，任何事情都是可能的。

原始的 danksharding 多维费用市场是什么样的？

Proto-danksharding 引入了一个多维 EIP-1559 费用市场，其中包含两种资源：gas 和 blob，具有单独的浮动 gas 价格和单独的限制。

即有两个变量和四个常量：

blob 费用是以 gas 收取的，但它是可变数量的 gas，它会调整以使每个块的平均 blob 数量实际上等于长期的目标数量。

二维性质意味着区块构建者将面临一个更难的问题：与其简单地接受具有最高优先级费用的交易，直到他们用完交易或达到区块气体限制，他们将不得不避免遇到两个不同的同时限制。

这是一个例子。假设 gas 限制为 70，blob 限制为 40。mempool 有很多交易，足以填满区块，并且有两种类型（tx gas 包括 per-blob gas）：

遵循朴素的“低优先级费用”算法的矿工将使用第一种类型的 10 笔交易（40 gas）填充整个区块并赚取 5 * 40 = 200 gas。由于这 10 个事务填满了 blob 完整限制，因此它们将无法包含更多事务。但最佳策略是进行 3 笔第一类交易和 28 笔第二类交易。这为您提供了 40 个 blob 和 68 个气体的块，以及 5 * 12 + 3 * 56 = 228 的收入。

现在执行的客户是否必须实施复杂的多维背包问题算法来优化他们的区块生产？不，有几个原因：

由于这些原因，更复杂的费用市场动态不会大大增加中心化或风险；事实上，应用更广泛的原则实际上可以降低 DoS 攻击的风险！

指数型 EIP-1559 blob 费用调整机制如何运作？

今天的 EIP-1559 调整基础费用 b 以达到特定的目标气体使用水平 t，如下所示：

其中 b(n) 是当前区块的基本费用，b(n+1) 是下一个区块的基本费用，t 是目标，u 是使用的气体。

这种机制的最大问题是它实际上并不针对 t。假设我们得到两个块，第一个 u=0，下一个 u=2t。我们得到：

虽然平均使用量等于t，但是basefee下降了63/64。所以basefee只有在使用率略高于t时才会稳定；在实践中显然高出约 3%，尽管具体数字取决于方差。

一个更好的公式是指数调整：

exp(x) 是指数函数 e^x，其中 e≈2.71828。对于x的小值，exp(x)≈1+x，但是它有一个与事务排列无关的方便性质：多步调整

仅取决于总和 u1+...+u/n，而不取决于分布。要了解原因，我们可以进行数学运算：

因此，包含的相同交易将产生相同的最终基本费用，无论它们如何跨区块分配。

上面最后一个公式也有一个自然的数学解释：（u1+u2+...+u/n-nt）这个术语可以看作是多余的：实际使用的总gas与打算使用的总gas之间的差异使用的区别。

当前的基本费用等于

清楚地表明，超出的范围不能超出一个很窄的范围：如果超过 8t∗60，那么 basefee 就变成了 e^60 ，高到没有人可以支付，如果低于 0，则资源基本上是免费并且链将被发送垃圾邮件，直到超出部分回到零以上。

调整机制 完全按照这些术语工作：它跟踪实际总额 (u1+u2+...+u/n) 并计算目标总额 (nt)，并将价格计算为差异的指标。为了让计算更简单，我们不使用e^​​x，而是使用2^x；事实上，我们使用 2^x 的近似值：EIP 中的 fake_exponential 函数。假指数几乎总是在实际值的 0.3% 范围内。

为防止长时间未充分利用导致长 2x 完整块，我们添加了一项额外功能：我们不会让多余的块低于零。如果actual_total 低于targeted_total，我们只需设置actual_total 等于targeted_total。在极端情况下（blob gas 一直降至零），这确实破坏了交易顺序的不变性，但增加的安全性使其成为可接受的妥协。还要注意这个多维市场的一个有趣结果：当最初引入 proto-danksharding 时，最初可能只有很少的用户，所以在一段时间内，一个 blob 的成本几乎肯定会非常便宜，甚至是“常规”。区块链活动仍然很昂贵。

作者认为这种费用调整机制比目前的方法更好，因此最终 EIP-1559 费用市场的所有部分都应该使用它。

有关更长更详细的解释，请参阅 Dankrad 的帖子。

fake_exponential 是如何工作的？

为方便起见，这里是 fake_exponential 的代码：

def fake_exponential(numerator: int, denominator: int) -> int: cofactor = 2 ** (numerator // denominator) fractional = numerator % denominator return cofactor + ( fractional * cofactor * 2 + (fractional ** 2 * cofactor) // 分母 ) // (分母 * 3)

这是在数学上重新表述的核心机制，去掉了四舍五入：

目标是将 (QX) 的许多实例连接在一起，每个 [2^k, 2^(k+1)] 范围被适当地移动和缩放。Q(x) 本身是一个近似值对于 0≤x≤1，为 2^x，选择以下属性：

最后三个需要三个未知系数的三个线性方程，上面给出的 Q(x) 给出了唯一解。

近似值出奇的好；对于除最小输入之外的所有输入，fake_exponential 给出的答案在 2^x 实际值的 0.3% 范围内：

proto-danksharding 在争论中还存在哪些问题？

注意：此部分很容易过时。不要相信它会就任何特定问题提供最新的想法。