以太坊EIP｜深入理解EIP-4844

声明：本文仅分享个人见解，不构成投资建议。

本文转载自公众号【GenesiSee】，原文发布时间：2023年05月19日

原文链接：以太坊EIP｜深入理解EIP-4844

坎昆升级将临，Layer2也成为了目前以太坊最火热的概念。近期小编将会整理一个Layer2系列，对Layer2涉及到的技术细节以及不同主流项目进行深入剖析。本文将从坎昆升级的核心提案EIP4844切入作为Layer2的开篇，尽可能用通俗的语言让大家对4844提案有一个更为清晰的了解。

1. Layer2现状

目前主流的Rollup项目都是通过calldata将数据上传至L1，但是 calldata 原始设计是专为交易参数而设计的，并且永久存储在以太坊的共识层和执行层，具有较高的 Gas 费用，根据Starkware的官方文档描述，当数据使用calldata进行存储时，更多费用会消耗在gas上，而非生成证明。

图片来源：https://l2fees.info/

根据l2fees网站公布的数据可以看得出，虽然相较于以太坊来说，L2的gas有所降低，但是仍未达到大家的预期。为了进一步降低gas费，EIP4844便应运而生。

2. EIP-4844详解

EIP4844最上层的设计思路是区别于calldata的方式进行存储，引入一个新的Blob交易类型，该类型与传统交易类型基本一致，不过Blob交易会携带一个额外的Blob数据。这个Blob数据非常大(~128KB)且相比calldata便宜很多，该部分数据EVM无法访问运行，只能查看对于该部分数据的承诺，且保存时间为1个月而非永久存储。

2.1 有趣的尝试 - EIP4488

上文提到过，多个L2项目的数据存储使用的是calldata进行存储，这样会导致gas费非常之高，为了解决这个问题，有两个方向可以进行探索：

• 降低calldata上传的数据量

• 降低calldata的存储开销

针对第一个点各大L2厂商对上传至calldata的数据压缩都进行了一定程度的探索。而EIP4488则是针对第二个点的提案，提案提到将每个非0字节的calldata的开销从16gas降低至3gas，旨在不对整体结构做出太大调整的情况下解决gas费的问题。

这个尝试最终没有被以太坊采纳，因为此提案涉及到了一个较难处理的问题：calldata会持久地存储在以太坊中，我们可以简单算一笔账，现在的情况下，如果我们将以太坊的gas上限全部用以调用数据，那么一个区块大小最大可以达到1.8M，而如果gas降低至1/5，那么最坏的情况下一个区块大小则会上升至9M，这个大小对于以太坊来说太大了，而且会让每个块的平均大小趋向于最差情况。

以太坊官方秉持着一个观点，即超过一年的数据，用户总能通过某些方式在一些地方找到，而不需要将数据同步至创世区块。而4844协议则是在此假设的前提下，保证对数据的可用性的情况下对数据进行修剪，而非持久存储。

2.2 新的交易格式 - SignedBlobTransaction

为了更好地支持 L2 数据的上链，EIP-4844 设计了新的交易格式 Blob, 如下图所示是 Blob 网络传输的相关字段，本节对 Blob 将涉及到的关键数据字段进行解释。

• Blob: 类型是Vector[uint256, 4096]，存储数据的 Blob 是一个长度为 4096 类型为 uint256 的数组。这是存储大量数据的字段，