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

原文作者：Chuan Lin，AnT Capital

图片来源：由 无界版图AI 工具生成

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 江湖。

（详见笔者之前关于 L2 的研究：万字长文：ETH 合并当下，对 Layer2 的回顾与展望 ）

而 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 的数据大小可以非常大，高达 125KB。

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

不能像 Calldata 那样被 EVM 所读取

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

（如果你对密码学和抽象代数并不熟悉，那么对于 blob 本身理解到这一层已经足够了）