前提

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

背景

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
为什么需要存储扩容
1. 以太坊的Rollup-centric Roadmap，围绕Rollup进行扩容
2. Rollup把计算安全地转移到了L2，但存储仍然旧留在L1
3. L1存储能力有限，限制了以太坊上Rollup的容量
  
   https://etherscan.io/chart/blocksize
一些L2的存储扩容方案
1. 例如Validium、zkPorter、Celestia、Polygon Avail
2. 降低了安全性：信任Ethereum网络保存数据→信任L2维护者保存数据
https://blog.celestia.org/celestiums/
需求：L1存储扩容
1. 安全性高：L1上每个节点都要验证并存储数据
2. 例子Arweave：节点需要60TB存储，且每天新增几百GB
3. L1的存储扩容对节点的存储和带宽要求过高
  
   https://viewblock.io/arweave/stat/cumulativeWeaveSizeHistory

Proto-Danksharding：降低存储要求

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]  // 一段时间后过期
```
降低了节点的存储要求：扩展存储→扩展缓存（Blobs）
1. 链上提供了一个较大的数据缓存空间
2. Blob相比Calldata是 Cache/内存：只保证曾经拥有，不保证天长地久
3. 缓存空间对节点的存储资源占用较低，因此收取较低的gas
  1. Multidimensional EIP-1559
与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
Blob的存储
1. Blob Transactions上链时，会把Blobs放到Beacon Chain存储
2. 因为Beacon Node的网络和存储压力远小于Execution Node
3. 未来DA Node应该是独立的
  
   https://hackmd.io/@vbuterin/sharding_proposal
安全性
1. Blob Data
  1. 等同L1
  2. 高于L2：信任Ethereum网络验证DA VS 信任L2网络验证DA
2. Historical Data
  1. 低于L1：信任Ethereum网络保存数据 VS 信任L2数据维护者保存数据
  2. 等于L2
EIP-4844，打算在The Merge之后的下一个分叉，上海分叉中引入

Danksharding：进一步降低带宽要求

如果Block包含更多的Blob，节点的带宽难以支持实时同步Block
1. Max 2 MiB，Target 1 MiB → Max 32 MiB，Target 16 MiB
进一步降低节点的带宽要求：下载Blob→抽查Blob
1. 节点对Blob进行随机抽查，然后对Block提交Attestation
  
  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/
安全性降低
1. 信任Ethereum网络至少有1个节点保存数据→至少有n个节点保存数据
2. 网络中需要有足够多的节点，才能保证Blob在全网充分抽查和备份