坎昆升级将临，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 的数组。这是存储大量数据的字段，总的大小为128KB。

• LIMIT_BLOBS_PER_BLOB：每个交易中允许存储的最大Blob数量，目前设置为2。

• blobs: 类型为[LIMIT_BLOBS_PER_BLOB]Blob，交易内存储的 Blob 列表，目前一个tx中最多允许存储两个Blob。

• KZGCommitment: KZG承诺信息，类型为 Bytes48。可以类比为 Blob 内信息的一种默克尔树根，比默克尔树的验证效率更高。它可以供验证者验证所提供的Blob数据和KZGCommitment信息是否一致。

• blob_kzgs: 类型为[LIMIT_BLOBS_PER_BLOB]KZGCommitment，是Blob的承诺列表，和blobs的长度一致，与blobs一一对应。

• KZGProof: 和KZGCommitment 的类型一致，用于承诺中的某个信息的证明。

• VersionedHash: KZGCommitment 的哈希，类型为 Bytes32。这是承诺存储在交易内的形式。为了缩短它的长度并使它兼容以太坊虚拟机所支持的Bytes32类型，VersionedHash 将 KZGCommitment 再做了一次哈希操作从48字节变成32字节。

• blob_versioned_hashes：类型为[LIMIT_BLOBS_PER_BLOB]VersionedHash，是一个VersionedHash列表，与blob_kzgs一一对应。

交易结构中的具体字段间的关联关系如下图所示：

图片来源：https://hackmd.io/@protolambda/blobs_l2_tx_usage

上图中我们可以看出Tx中并不会对blobs进行持久化存储（但并非不进行存储，详情可以参见后文），仅保存blob_versioned_hashes，相较于以往的calldata存储数据，这种设计方式会大大减少L1的存储压力。

2.3 Blob 相关数据结构的构造和使用

blob 中的数据结构中最核心的一个是关于承诺的构造，一个是关于证明的构造，我们先来看看承诺的构造：

tx / state diff -> blob -> KZGCommitment -> VersionedHash

首先，我们将需要提交上链的数据（交易列表或者是状态的变更）以上文提到的blob的格式进行组装形成相应的数据向量；其次也是最重要的一步，将 Blob 格式的数据按照 KZG承诺的算法来构建相应的数据承诺，最后将对承诺做 Keccak256 哈希就形成了交易体中存储的 VersionedHash 了。

这里采用了一种常见的多项式承诺算法：卡特承诺（KZGCommitment）, 这种承诺算法有几个要点：一个是可以将大量的 blob 数据压缩成固定大小的承诺信息，二是可以在将来对承诺中某个单个数据进行证明而不用暴露整个承诺的底层数据。这对区块链这种 gas 敏感性计算平台而言无疑是当下最好的选择。

承诺生成：

我们再一起看看关于 blob 中的数据如何进行验证，大概的用法如下：verify(tx[i] + kzg_commitment + kzg_proof) 通过给定具体的交易，交易提交时的承诺，以及交易对应的证明信息即可验证交易的合法性。

以下是协议中给出的伪代码，验证内容包括：1. 承诺信息的哈希生成是否有问题；2. KZG 证明，可以证明相应的数据是否是在所承诺的曲线上；

这里不对相应背后的数学细节做展开了，有兴趣的读者可以自行阅读这篇文章。

point_evaluation在OP 的欺诈证明中的应用流程，简单流程如下：

图片来源：https://hackmd.io/@protolambda/blobs_l2_tx_usage

2.4 Blob 交易的生命周期

在了解了 Blob 交易的格式以及相应字段的构造原理之后，我们再一起来了解一下在 L2-L1 混合生态中，新的 Blob 交易是如何流转的，又会对哪些组件产生影响。

图片来源：https://hackmd.io/@protolambda/blobs_l2_tx_usage

1. 当一个用户在 L2 上进行交易时，它会被 Rollup 节点打包成进入 Blob 进而构建 Blob 交易，数据会被存储在 Vector[uint256, 4096] 类型的 Blob 中。

2. 这个 Blob 交易会被提交到以太坊主网。这里有个特别的设计，Blob 交易虽然是一种新的交易格式，但是Blob交易体中并不包含blobs 数据，blobs 数据是采用了一种称为 sidecar 的设计模式独立于 Blob 交易之外的，并且有一定的生存期。也就是说 blobs 数据被存储在了数据层而非L1上，且只保持一段时间（一个月）的可用性。根据以太坊官方的说法，他们并不会为这些数据提供永久的存储，他们更希望更多的第三方可以承担起存储的责任，不过他们会保证数据在被剪枝删除之前有足够长的窗口期供各大第三方拉取。

Beacon chain 因此需要做出如下几点改造：

• Beacon chain: 处理更新后的区块，并为 blobs 提供可用性保障；

• P2P network : gossip 以及同步新的 beacon 区块类型以及新的 blob sidecars;

• Honest validator: 产生携带blobs 的区块链，并发布 blobs sidecars;

图片来源：https://hackmd.io/@protolambda/blobs_l2_tx_usage

2.5 Blob 交易的 Gas 费调节机制

为了防止 Blob 交易对整个以太坊网络的交易价格和稳定性产生不可预测的影响，Blob 交易的 gas 费调节采用了类似于 EIP-1559 的市场调节机制。具体来说，当 Blob 的使用度较高时，gas 费用会显著增加，以降低 Blob 的使用并使 gas 在目标值范围内保持稳定。

价格公式如下：

data_gasprice = MIN_DATA_GASPRICE * e^(excess_data_gas / DATA_GASPRICE_UPDATE_FRACTION)

其中，excess_data_gas 是链上额外消耗的 gas 费用，与 TARGET_DATA_GAS_PER_BLOCK 有关。这是一种自动调节机制，使得 data_gasprice 与过量 gas 之间呈现指数关系，从而防止过大的数据量对整个系统造成破坏。

具体而言，块与块之间的价格调节遵循以下规则：假设块 N 消耗了 X 数据 gas，则在块 N+1 中，excess_data_gas 增加 X-TARGET_DATA_GAS_PER_BLOCK，同时，块 N+1 的 data_gasprice 增加 e^((X-TARGET_DATA_GAS_PER_BLOCK) / DATA_GASPRICE_UPDATE_FRACTION) 的比例。因此，该机制在总体使用情况相同时，具有与现有 EIP-1559 类似的效果，但相较之下，其响应性更加稳定。

图片来源：https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#What-does-the-proto-danksharding-multidimensional-fee-market-look-like

3. EIP-4844 利好应用

EIP-4844 协议的实施无疑是一个对整个加密领域及去中心化金融市场的积极变化。通过降低 L2 交易结算的 gas 费用，将显著降低用户参与 Layer 2 解决方案时的门槛。这不仅对 L2 基础设施的发展提供了强大的动力，而且还将吸引更多的项目开发者和用户参与到 L2 生态中来，推荐关注 L2 基础设施类项目及生态中的龙头产品。

随着交易费用的降低，更多的小额交易和智能合约操作将变得切实可行，为去中心化应用（DApp），特别是高频应用的广泛应用铺平道路。这将极大地推动 L2 生态的繁荣，吸引各类新项目和创新应用融入其中，不仅使得市场竞争更加激烈，也将为用户提供更加丰富的金融工具和服务。

4. 迈向 Danksharding

EIP-4844（Proto-Danksharding） 是迈向 DankSharding 最终形态的重要一环，其核心目标在于大幅降低 L2 用户的参与门槛。Proto-Danksharding 协议已逐渐成熟，各项生态组件正稳步推进中。对于关注该协议发展的读者，建议关注：

EIP 4844 readiness checklist

https://github.com/ethereum/pm/blob/master/Breakout-Room/4844-readiness-checklist.md#client-implementation-status

DankSharding 是以太坊完全分布式架构的终极目标，旨在实现高度可扩展、安全且去中心化的网络，支持超过 100,000 TPS 的处理能力。在实现 DankSharding 的道路上，还需解决诸如 Proposer 和 Builder 的分离、数据可用性抽样以及无状态客户端实现等关键技术挑战。

随着以太坊在性能、安全性和扩展性方面的持续优化，将使得该网络更具吸引力，有望促使更多的用户从其他竞争对手区块链平台转向以太坊。这种趋势也将进一步加强以太坊在区块链行业的主导地位，巩固其作为全球最大智能合约平台的地位。

参考文档

1. https://eips.ethereum.org/EIPS/eip-4844

2. https://www.eip4844.com/

3. https://scroll.io/blog/kzg

4. https://github.com/ethereum/consensus-specs/tree/23d3aeebba3b5da0df4bd25108461b442199f406

5. https://www.chaincatcher.com/article/2088707

6. https://www.chaincatcher.com/article/2086654

7. https://dankradfeist.de/ethereum/2021/10/13/kate-polynomial-commitments-mandarin.html

8. https://hackmd.io/@protolambda/blobs_l2_tx_usage

9. https://medium.com/taipei-ethereum-meetup/ethereum-%E6%95%88%E8%83%BD%E7%93%B6%E9%A0%B8%E8%88%87%E6%94%B9%E5%96%84%E6%96%B9%E6%A1%88-4e791ab76415