一 提出EIP-4844的背景是什么?
1.1 以太坊扩容必要性
以太坊1.0采用PoW，面临能源消耗问题；以太坊网络用户量增加，交通拥堵，提升了交易成本，降低了交易效率。面临这样的问题，所以以太坊需要扩容。
1.2 信标链和以太坊主链进行合并
2022年，信标链和以太坊主链进行合并，完成了以太坊2.0阶段的The Merge阶段，将原来的PoW共识机制，替换成了PoS权益证明共识机制。
信标链升级，导致共识层客户端和执行层客户端发生了分离。提供了共识管理和验证者管理。
1.3 现有的扩容方案存在的问题
现在扩容的话主要包含链上和链下两种扩容路线：链下主要包括通道、侧链、plasma、rollup等等；链上主要就是sharding分片方案。
1.3.1 分片链
对于链上方案来说，采用分片链。即从以太坊从原本的一条主链被设计为了最多 64 条分片链，通过增加多条新链的方式来实现扩容。在这个方案中，每条分片链负责处理以太坊的数据并交给信标链，信标链则负责整个以太坊的协调。 这个方案也有些问题:
第一: 对于信标链而言，每隔一个Epoch周期之后，重新选举委员会成员，会重新分配验证节点，那么就是一次大规模网络的数据同步。
第二: 把以太坊分割成 64 条分片链的同时还要确保可以正常运行，在技术上要实现十分困难
1.3.2 Layer2扩容
针对链下扩容等方案，比如Op Rollup等，他们会批量收集链下交易，压缩之后提交到了L1主链，这种方案虽然相比于以前性能有所提升，Gas成本有所下降，但是效果不是特别显著。
第一: Layer2基于calldata数据压缩后存储到Layer1，虽然用户gas fee有所减少，但是在拥堵的时候gas fee还是比较高
第二: Layer2可以将一些数据存储在DA上，但是DA的话，提供商可能存在跑路的风险，可能交易还没有被验证，DA就跑路了，这样用户交易永远无法被验证
1.4 采用DankSharding扩容
Danksharding 使用了一套新的分片思路去解决以太坊的扩容问题，即围绕着 Layer2 的 Rollup 进行扩容的分片方案，这套新的分片方案可以在不大量增加节点负担且保证去中心化和安全性的同时解决可扩展性问题，同时也解决了 MEV 带来的负面影响。那么EIP-4844就是在在这样的背景提出来的，作为Danksharding前置步骤，因此EIP-4844也被叫Proto-Danksharding。
总结:
第一: 以太坊需要扩容
第二: 目前的扩容方案，都还面临一些挑战
第三: 提出DankSharding方案，EIP-4844随之被提出
二 EIP-4844
2.1 什么是EIP-4844
第一: EIP-4844是一个以太坊完整分片DankSharding的前置方案, 因此也叫作proto-danksharding
第二: 它引入了一种新的交易类型，叫做blob-carrying transaction,它可以存储大量数据和大块数据。Blob transaction和普通交易区别不大，只不过blob transaction会携带一份额外数据，叫做blob而已
第三: blob transaction被用户在二层提交后，会存储到beacon chain信标链上，而不是存储在主链上的; 但是用户交易状态数据还是会存储到主链上
第四: 存储在信标链上的blob transaction有一个存储期限，并不是无限长存储，一般来说是30天后会被删除
第五: 信标链上的交易数据删除了，用户怎么查询呢？以太坊共识协议的目的不是保证永远存储所有历史数据。相反，目的是提供一个高度安全的实时公告板，并为其他去中心换协议留下空间来进行长期存储
第六: 存储在信标链上的blob交易数据，不能被EVM访问
2.2 4844规范
2.2.1 Blob Type
就是以太坊信标链接收Blob类型的交易数据短暂存储。注意，Blob交易数据并不是存储到主链上的，而是信标链。并且有时间限制，过一段时间，这些数据会被删除掉。引用Cyfrin的一张图：
另外，这里只是将Blob数据存储在信标链上，但是Blob元数据是在以太坊主链上的。如图所示，元数据存储在L1链上：
2.2.1.1 什么是Blob 存储类型
Blob我们可以认为是一种数据结构或者存储结构，他可以用来存储一些用户数据、版本信息、数据承诺与证明等
2.2.1.2 Blob包含哪些字段信息
Blob(用户数据)
第一: 该字段是Blob 的实际数据内容，由固定大小的ByteVector字节向量组成, 存储用户数据。
第二: 每一个Blob中可以存储FIELD_ELEMENTS_PER_BLOB个元素，默认是4096；然后每一个元素占BYTES_PER_FIELD_ELEMENT字节，默认是32字节
第三: 字节向量ByteVector大小就是BYTES_PER_FIELD_ELEMENT * FIELD_ELEMENTS_PER_BLOB = 32 * 4096 = 131072 字节 (128 KB)
VersionedHash(Blob版本哈希)
Blob 的版本哈希，32字节，用于验证 blob 数据的一致性和版本
KZGCommitment(数据承诺)
数据承诺是一个48字节的字段，表示零知识证明承诺，用于确保数据的完整性
KZGProof(证明)
证明也是一个48字节的数据，用于验证承诺的证明
举一个例子：
{
Blob Versioned Hash: 0xdef...456,
Blob Data: [binary data 2],
KZG Commitment: 0xabc...789,
KZG Proof: 0x123...def
}
2.2.2 Blob Carry Transaction
2.2.2.1 什么是Blob Carry Transaction或者Blob Transaction
Blob Carry Transaction表示当前的交易类型是携带Blob的交易类型。
Blob Carry Transaction是一种符合EIP-2718标准的交易类型。使得后续引入新的交易类型可以向后兼容。
2.2.2.2 Blob Carry Transaction和 EIP-2718
Blob Carry Transaction是一种符合EIP-2718标准的交易类型。我们知道，EIP-2718可以理解为一种交易框架，使得后续引入新的交易类型可以向后兼容。
TransactionType: 指定了交易类型，它是一个0x0-0x7f之间的8位无符号的正数，比如Blob Transaction中TransactionType 为 BLOB_TX_TYPE，几表示其值为Bytes1(0x03)
TransactionPayload: 表示交易负载, 它是对交易数据体TransactionPayloadBody进行RLP序列后之后的数据，即即TransactionPayload = rlp(TransactionPayloadBody) TransactionPayloadBody：[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s]。这些字段中，chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, value, data, and access_lis是EIP-1559就有的字段；max_fee_per_blob_gas, blob_versioned_hashes是和Blob Transaction相关的字段；y_parity, r,s是和签名相关的字段
Blob Transaction常规字段:
chain_id：链 ID 。
nonce：账户的交易计数器。
max_priority_fee_per_gas：每单位Gas用户愿意支付给矿工的最大小费是多少
max_fee_per_gas：每单位Gas用户愿意支付的最大价格是多少
gas_limit：交易可使用的最大gas 量。
value：以 wei 为单位的发送的以太币数量。
data：交易的输入数据。
access_list：一个访问列表，包括交易执行过程中需要访问的地址和存储键，以优化 gas 消耗和提高交易执行效率。
blob 交易独有字段：
max_fee_per_blob_gas ：用户指定的愿意给出的每单位 Blob Gas的最大费用。
blob_versioned_hashes：Blob 的版本哈希，32字节，用于验证 blob 数据的一致性和版本
ReceiptPayload
表示Blob交易收据，消息体是([status, cumulative_transaction_gas_used, logs_bloom, logs])
ReceiptPayload = rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])
status：交易执行的状态码（成功或失败）。
cumulative_transaction_gas_used：执行到当前交易为止累计的 gas 消耗量。
logs_bloom：交易产生的日志的Bloom过滤器，用于快速检索日志事件。
logs：交易执行过程中产生的日志事件列表。
Signature：
Blob交易的发送者对交易数据进行的数字签名，先将 BLOB_TX_TYPE 与 TransactionPayload 的拼接结果进行 keccak256 哈希处理，获得摘要如下：
keccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes]))
再将摘要进行 secp256k1 签名 获得签名值 y_parity、r 和 s
三 数据超过一定时间被删除，用户想访问旧数据怎么办?
第一: 以太坊共识协议的目的不是永久保证所有历史数据的存储
第二: 如果用户想访问历史数据，可以通过第三方服务提供商比如TheGraph等去订阅对应的数据然后进行保存；如果是Layer2链上，用户可以从Layer2链上拉取数据
四 EIP-4844 还存在哪些问题
EIP-4844 实现了以太坊围绕 Rollup 进行扩容的第一步，但对于以太坊来说 EIP-4844 达到的扩容效果是远远不够的。完整的 Danksharding 方案将 Blob 可以承载的数据量从每个区块 1MB~2MB 进一步扩充至 16MB~32MB
那么我们需要知道要在 EIP-4844 的基础上继续进行扩容会存在哪些难题：
4.1 节点负担过大
我们知道 EIP-4844 中只有 1MB~2MB 大小的 Blob 对节点增加的负担是完全可以接受的，但如果将 Blob 的数据量扩大 16 倍至 16~32MB 的话，不管是在数据同步还是数据存储上的负担都会使得节点的负担过大从而以太坊的去中心化程度降低。
4.2 数据可用性问题
如果节点不去下载全部的 Blob 数据，就会面临数据可用性问题，因为数据不在链上开放且随时可访问，比如以太坊节点对 Optimism Rollup 上的某笔交易存疑想发起挑战，但 Optimism Rollup 不交出这段数据，那么拿不到原始数据就无法证明这个交易是有问题的，所以要解决数据可用性问题就必须确保数据是随时开放且可访问。