<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

    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

      https://etherscan.io/chart/blocksize

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

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

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

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

  4. 需求:L1存储扩容

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

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

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

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

      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/内存:只保证曾经拥有,不保证天长地久