# EIP-4844 解决了什么问题

By [Untitled](https://paragraph.com/@0xc9a58ac2c79beca2e7a3e152191ce1ef305264b3) · 2023-03-01

---

前言
==

L2 为确保 **“数据可用性”** 需要将数据压缩发送到 L1，然而目前数据都是存储在交易的 Calldata 中的。然而 Calldata 最初的设计并不是服务于该种场景的，通过 Calldata 存储数据是一件成本比较高的事情。

L2 的数据与合约数据的区别在于，L2 的数据并不需要被 L1 执行，也就是说，在 L1 同步区块阶段，实际上是没必要全网实时同步该部分数据的。

因此 EIP-4844 围绕该问题，推出了全新的数据类型，以跟 Calldata 区分开，这类数据只需要确保全网可访问下载，无需全网做到实时同步

Blob 数据类型
=========

二进制大数据块（Binary Large Object —— Blob），与 Calldata 不同，其大小可高达 125 KB

**同时，Blob 数据不会上主链，而将会由共识层的节点进行存储，且具有生命周期，将在 30 天后被删除 「说好的 DA？？」**

![](https://storage.googleapis.com/papyrus_images/47a4af2040f23c63e71bf6d1e475d805dd3735c1f55128f407d3fb185c375844.png)

*   L2 Sequencer 确定交易，将交易的结果和相关证明（黄色部分）和数据包（Blob，蓝色部分）传到 L1 的交易池中
    
*   Beacon Proposer 看到了交易，它会在新的区块提议（Beacon Block）里面执行相关交易并进行广播；但在广播的时候，它会把 Blob 分离出来留在共识层 CL 中，并不会把它放到执行层的新区块里面
    
*   其它 L1 节点（Beacon Peer）会收到了新的区块提议和交易结果。如果它们有需要成为 L2 验证者，它们可以去 Blobs Sidecar 下载相关的数据。
    

![](https://storage.googleapis.com/papyrus_images/27c873da66fe215fde28fd101598c36c1bbc3f5102b0edadb86854ca693424f2.png)

---

*Originally published on [Untitled](https://paragraph.com/@0xc9a58ac2c79beca2e7a3e152191ce1ef305264b3/eip-4844)*