<aside> 💡 EIP-4844, Danksharding, PBS, DAS, KZG, Celestia, Avail

</aside>

前提

1. 掌握Rollup基本原理
2. 了解Ethereum PoS共识算法

背景

1. Rollup的DA（Data Availability）问题

   

   https://messari.io/article/polygon-a-multi-sided-approach-to-zk-scaling

   1. Rollup必须保证数据的Publicly Available
      1. Batch
      2. State
   2. 如果DA无法保证
      1. OP-Rollup：无法challenge某次提交（State & Batch）
      2. ZK-Rollup：无法继续提交（State）
   3. 为了保证DA，Batch通过Calldata提交到L1

2. 为什么需要存储扩容

   1. 以太坊的Rollup-centric Roadmap，围绕Rollup进行扩容

   2. Rollup把计算安全地转移到了L2，但存储仍然旧留在L1

   3. L1存储能力有限，限制了以太坊上Rollup的容量

      

      https://etherscan.io/chart/blocksize

3. 一些L2的存储扩容方案

   1. 例如Validium、zkPorter、Celestia、Polygon Avail
   2. 降低了安全性：信任Ethereum网络保存数据→信任L2维护者保存数据

   

   https://blog.celestia.org/celestiums/

4. 需求：L1存储扩容

   1. 安全性高：L1上每个节点都要验证并存储数据

   2. 例子Arweave：节点需要60TB存储，且每天新增几百GB

   3. L1的存储扩容对节点的存储和带宽要求过高

      

      https://viewblock.io/arweave/stat/cumulativeWeaveSizeHistory

Proto-Danksharding：降低存储要求

1. Blob Transaction

   1. 增加一种新的交易类型，这种交易包含额外的存储空间——Blobs
   2. Blob有128 KiB的存储空间
      1. 一个交易最多包含2个Blob，即256 KiB
      2. 一个Block最多包含16个，即2 MiB；Target是8个，即1 MiB
   3. Blob以KZG Commitment Hash作为Hash，用于数据验证，作用和Merkle类似
   4. 节点同步链上的Blob Transaction后，Blob部分会在一段时间后过期删除

   class BlobTransaction():
       nonce: uint64
       gas: uint64
       max_basefee: uint256
       priority_fee: uint256
       to: Address
       value: uint256
       data: Bytes
       blob_versioned_hashes: List[VersionedHash]
   
       blobs: List[Blob]  // 一段时间后过期
   

2. 降低了节点的存储要求：扩展存储→扩展缓存（Blobs）

   1. 链上提供了一个较大的数据缓存空间
   2. Blob相比Calldata是 Cache/内存：只保证曾经拥有，不保证天长地久