一文读懂EIP-4844：如何降低Layer2费用100倍？

原文作者：Chuan Lin

原文来源：A&T Capital

01、引子

Vitalik 于 2022 年 11 月 5 日发布了更新后的以太坊路线图，相比于之前 2021 年 12 月 2 日发布的路线图，其中即将到来的 The Surge 阶段的更新无疑是最值得关注的。

如下图所示，这一阶段的更新明显添加了更多细节 —— 我们可以明显看到，为了实现“基本的 Rollup 扩容”，以太坊社区提出了 EIP-4844 ：Proto-Danksharding。这个提案将于 2023 年 5 月到 6 月初落地，届时 Rollup 的费用花费将降低 100 倍，这将非常大的优化以太坊L2的用户体验。如此大的优化，势必会成为Web3社区讨论和关注的焦点。

原来以太坊相关的问题在哪？EIP-4844 是用什么思路和方案解决这一问题的？本文就将帮助大家简明扼要的理解 EIP-4844 。

如果你希望跟上以太坊底层的架构更新，实时跟上社区的讨论，就请不要错过本文！

02、正文

一、EIP-4844 起源：数据可用性引起的L2费用瓶颈

1.1 当前有关L2与L1数据交互的基本情况

当前以太坊L2大多以 Rollup 为基本的技术路线，Vitalik 更是将以太坊的更新用”A Rollup-Centric Roadmap“描述，可见 Rollup 基本已经一统L2江湖。

而 Rollup 运行的基本原理，是将一捆交易在以太坊主链外执行，执行完后将执行结果和交易数据本身经过压缩后发回到L1上，以便其他人去验证交易结果的正确性。 显然，如果其他人没有办法读取数据，那就无法完成验证。因此让其他人能够获取交易原始数据这一点非常重要，它也被称为“数据可用性”（Data Availability）。

而受限于以太坊当前的架构，L2向L1的传输的数据，是储存在交易的 Calldata 里面的。 然而，Calldata 在最初以太坊设计的时候只是一个智能合约函数调用的参数，是所有节点必须同步下载的数据。如果 Calldata 膨胀，将造成以太坊网络节点的高负载，因此 Calldata 的费用是比较昂贵的。这也是造成当前L2费用的主要因素。

1.2 问题的改进思路

读者不妨思考一下，如果让你来针对这个问题设计优化方案，你会朝哪个方向去做改进？

其实我们可以观察到，L2的交易压缩数据的上传，只是为了让它能够被其他人所下载验证，并不需要被L1所执行。而 Calldata 费用之所以高，是因为它作为一个函数调用的参数，是默认可能被L1执行的，因此需要全网的节点进行同步。

这就造成了一种不匹配：打个比方，就像我明明只想把数据传个网盘，让有需要的其他人在一段时间内能够去下载；结果，你却把我的数据做了个我并不需要的全网广播同步，强制所有人必须在限定时间内完成下载，然后反过来因为这个服务向我收取高昂的费用。这明显是不合适、需要改进的。

那怎么改进呢？ 我们可以把L2传过来的数据单独设计一个数据类型，把它和L1的 Calldata 分开。这种数据类型只需要满足能在一定时间内被有需要的其他人所访问下载即可，无需做全网的同步 。 实际上，这点也被众多以太坊技术社区的成员所想到了。

EIP-4844 的改进，其实就是围绕着这个脉络进行的。

二、EIP-4844 的核心：带 Blob 的交易

如果用一句话来概括 EIP-4844 究竟做了什么，那就是：引入了 ”携带 blob 的交易“ 这一新的交易类型。Blob 就是上文提到的，为L2的数据传输所专门设计的数据类型。

因此，将有关 blob 的细节理解清楚，就可以说基本搞明白了 EIP-4844 。

2.1 Blob 的本体：一个用于放置L2压缩数据的“大数据块“，存在共识层的节点中

Blob 这个名字，其实是 Binary Large Object 的简称，直译”二进制大数据块“。它被设计出来，就是为了承载L2的原始交易压缩数据，相当于之前L2的这些数据放到 Calldata，现在就放到 Blob 里面。相比于 Calldata，Blob 的数据大小可以非常大，高达 125 KB。

Blob 是由共识层的节点进行存储的，而不是像 Calldata 那样在会直接上主链，这也带来了 Blob 的两个核心特点：

• 不能像 Calldata 那样被 EVM 所读取

• 有生命周期，在 30 天之后将被删除

更细节一点的来说，Blob 本身，是一个由 4096 个元素所构成的向量（Vector）。这个向量每个维度都是一个可以非常大的数字，取值范围在 0 到 52435875175126190479447740508185965837690552500527637822603658699938581184513 之间 —— 这个非常大的数字是一个质数，它是和椭圆曲线密码学算法相关的。

而这个向量的每个维度的数字，可以把它看做是一个不高于 4096 阶的有限域多项式的各个系数，比如第 i 维的数字就是 w^i 前面的系数，其中 w 为常数且满足 w^ 4096 = 1 。这个结构设计，是为了方便 KZG 多项式承诺的生成。

2.2 与 Blob 相关的架构设计：Sidecar

在理解 Blob 架构之前，先需要说明一个概念：Execution Payload（执行负载）。在以太坊合并之后，分出了 Consensys Layer 和 Execution Layer，它们分别负责两个主要功能: 前者负责 PoS 共识，后者执行 EVM。而 Execution Payload 可以简单认为是 EL 层里面普通的L1交易。

Blob 和现在以太坊架构的融合，可以类比为摩托车本体和摩托车挎斗（Sidecar）之间的关系，就像这样：（左边的就是摩托车的 Sidecar）

Sidecar（摩托车挎斗）是一个官方比喻。它的含义，其实就是 Blob 的运转虽然依赖于主链，但某种程度上也平行于主链、具备相当的独立性。

如下图所示，接下来就让我们来过一遍 Blob 相关的执行流程，以更好的理解这一比喻：

• 首先，L2 Sequencer 确定交易，将交易的结果和相关证明（黄色部分）和数据包（Blob，蓝色部分）传到L1的交易池中

• L1的节点（Beacon Proposer）看到了交易，它会在新的区块提议（Beacon Block）里面执行相关交易并进行广播；但在广播的时候，它会把 Blob 分离出来留在共识层 CL 中，并不会把它放到执行层的新区块里面

• 其它L1节点（Beacon Peer）会收到了新的区块提议和交易结果。如果它们有需要成为L2验证者，它们可以去 Blobs Sidecar 下载相关的数据。

下图是从另一个角度对 Blob 生命周期的阐述，我们可以清晰地看到 blob 数据不会上L1主链，只会存在共识层节点之中，并且它有着不一样的生命周期。

因此， 这也不难理解为什么 Blob 无法被 EVM，也就是L1的智能合约所直接读取：能被读取的都是被传到执行层的东西，既然 Blob 仅仅留在共识层，那么肯定就没有这个功能了。 而事实上，这种分离，也正是 Rollup 费用能因此降低的原因。

2.3 Blob 的存储：新的 Fee Market

前文提到，Blob 数据将存在共识层节点之中，并且具备生命周期。但显然这种服务也不是免费的，因此它将会带来一个独立于L1 Gas 费的新费用市场，这也是 Vitalik 所倡导的 Multi-dimensional Fee Market。这个 Fee Market 的相关细节还在迭代完善之中，详见 Github 的相关讨论与更新

另外，如果节点层面只能短期存储这些数据，那么如何实现长期的储存呢？对此，Vitalik 表示解决方案其实很多。因为这里的安全假设要求不高，是” 1 of N 信任模型“，只需有人能够完成真实数据的存储即可。在大的存储硬件只需要 20 美元每 TB 的当下，每年 2.5 TB 的数据存储对于有心人而言只是小问题。另外，其它各种去中心化存储解决方案也会是一种选择，不过 Vitalik 在这里并没有提到具体的项目。

三、EIP-4844 的影响

在架构层面，EIP-4844 引入了新的交易类型 Blob-carrying Transaction，这是以太坊第一次为L2单独构建数据层，也是之后 Full Danksharding 实现的第一步。

在经济模型层面，EIP-4844 将为 blob 引入新的 Fee Market，这也会是以太坊迈向 Multi-dimensional Market 的第一步。

在用户体验层面，用户最直观的感知就是L2费用的大幅降低，这个底层的重要改进，将为L2以及其应用层的爆发提供重要基础。

四、EIP-4844 后的展望：Fully Danksharding

目前， EIP-4844 已经明确包含在以太坊上海升级系列之中，按照目前社区成员给出的时间表，预计将于明年 5 月至六月初完成。

而 EIP-4844 只是”Proto-Danksharding“，意为 Danksharding 的原型。完整版 Danksharing 的构想如下图所示，每个节点都可以直接通过数据可用性采样（Data Availability Sampling），实现对L2数据正确性的实时验证。这将会进一步提高L2的安全性和性能。