<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/内存：只保证曾经拥有，不保证天长地久
    3. 缓存空间对节点的存储资源占用较低，因此收取较低的gas
      1. Multidimensional EIP-1559

  3. 与Rollup结合

    1. Rollup用Blob提交Transaction Batch
      1. ZK-Rollup为例：Calldata传入KZG Commitment，合约执行时和从Opcode拿到的KZG Commitment Hash对比验证
    2. Rollup需要自行存储历史数据，建立State

    https://ethresear.ch/t/a-design-of-decentralized-zk-rollups-based-on-eip-4844/12434

    https://ethresear.ch/t/a-design-of-decentralized-zk-rollups-based-on-eip-4844/12434

  4. Blob的存储

    1. Blob Transactions上链时，会把Blobs放到Beacon Chain存储

    2. 因为Beacon Node的网络和存储压力远小于Execution Node

    3. 未来DA Node应该是独立的

      https://hackmd.io/@vbuterin/sharding_proposal

      https://hackmd.io/@vbuterin/sharding_proposal

  5. 安全性

    1. Blob Data
      1. 等同L1
      2. 高于L2：信任Ethereum网络验证DA VS 信任L2网络验证DA
    2. Historical Data
      1. 低于L1：信任Ethereum网络保存数据 VS 信任L2数据维护者保存数据
      2. 等于L2

  6. EIP-4844，打算在The Merge之后的下一个分叉，上海分叉中引入

Danksharding：进一步降低带宽要求

  1. 如果Block包含更多的Blob，节点的带宽难以支持实时同步Block

    1. Max 2 MiB，Target 1 MiB → Max 32 MiB，Target 16 MiB

  2. 进一步降低节点的带宽要求：下载Blob→抽查Blob

    1. 节点对Blob进行随机抽查，然后对Block提交Attestation

      https://hackmd.io/@vbuterin/sharding_proposal

      https://hackmd.io/@vbuterin/sharding_proposal

    2. 只要有足够多的Attestation，就认为Block（中的Blob）是Available的

    3. Blob分散地存储在网络中

    4. 虽然每个节点只保存Blob的数据片段，但是全网是有Blob的完整数据的

      https://dougvitale.wordpress.com/2012/02/01/bittorrent-how-it-works-and-how-to-use-it/

      https://dougvitale.wordpress.com/2012/02/01/bittorrent-how-it-works-and-how-to-use-it/

  3. 安全性降低

    1. 信任Ethereum网络至少有1个节点保存数据→至少有n个节点保存数据
    2. 网络中需要有足够多的节点，才能保证Blob在全网充分抽查和备份