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

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。

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

正文

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

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

不能像Calldata那样被EVM所读取

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

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

更细节一点的来说，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交易。

（来源：OP in Paris: OP Lab's Protolambda walks us through EIP-4844）

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

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

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

（来源：OP in Paris: OP Lab's Protolambda walks us through EIP-4844）

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

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

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

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

（来源：OP in Paris: OP Lab's Protolambda walks us through EIP-4844）

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

2.3 Blob的存储：新的Fee Market

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

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

（来源：Frequently Asked Questions Written by Vitalik Buterin）