少下载、少计算，凭什么仍然可信？

想象一家城市级清算所。商户把一整天的交易在店内处理，晚上只把账目摘要和必要凭证送到清算所。清算所不必逐笔重新收银，却必须回答三件事：账是按规则算的吗？任何人都能拿到账本重算吗？最终结果得到全城共同承认了吗？

Rollup 把大量执行移到 L2，再借以太坊获得数据可用性与结算安全。于是，以太坊扩容路线的中心问题从“L1 怎样亲自执行每一笔交易”，转向“L1 怎样以更小负担，仍然提供足够强的验证与数据保证”。本课目录的正式主题是 “Proto-Danksharding、Danksharding 与 ZK 技术”，它恰好对应这套转变。

如果 L2 只告诉以太坊“新状态根是 X”，却不公开产生 X 所需的数据，外部观察者就无法重建状态、验证余额，也无法在排序器失灵时自行退出。于是，Rollup 必须向某个数据可用性层发布足够的数据。

EIP-4844 之前，Rollup 主要把这些字节塞进交易的 calldata。Calldata 会进入执行负载并长期保留，价格还与普通 L1 执行共用资源和费用逻辑。对只需要“让数据短期公开，以便任何人抓取并重建 L2”的 Rollup 来说，这像是为了租一辆短途货车，顺便买下整座永久仓库。

Proto-Danksharding 就是 EIP-4844。它没有完成全部数据分片，却先规定了未来 Rollup 应该怎样把数据交给以太坊。这样，Rollup 只需从 calldata 迁移到 Blob 一次；以后底层从“每个节点下载全部 Blob”升级到抽样，交易格式无需推倒重来。

EIP-4844 随 Dencun 于 2024 年 3 月 13 日激活。Pectra 在 2025 年 5 月通过 EIP-7691 提升 Blob 吞吐。Fusaka 于 2025 年 12 月带来 PeerDAS，随后两次 Blob Parameter Only 升级继续提高容量。这个演进说明：Proto 是前向兼容的协议地基，不是临时演示网络。

Blob 是 binary large object 的简称。EIP-4844 的一个 Blob 由 4,096 个字段元素组成，每个元素 32 字节，所以原始容量为 131,072 字节，约 128 KiB。它通常承载压缩后的 L2 交易批次数据。

Blob 交易是类型 0x03 的 EIP-2718 typed transaction。交易正文包含 blob_versioned_hashes 与愿意支付的 Blob 费用；Blob 本体、KZG 承诺与证明作为网络侧的 sidecar 一起传播。执行层可以通过 BLOBHASH 取得版本化哈希，却不能像读取 calldata 那样读取 Blob 每一个字节。

Rollup 需要一段窗口，让任何观察者下载批次、验证或重建 L2 状态。只要数据在窗口内公开，诚实参与者就能把它复制到自己的节点、索引器或归档服务。之后，L1 只需永久保存对数据和结算结果的承诺，不必让所有共识节点永久背负每个字节。

这不是说数据“18 天后必然消失”，而是说协议的共识保证到此为止。要查询古老 Blob，应依赖 L2、归档节点或其他历史数据服务；要验证已经结算的 L1 状态，则依赖链上保存的承诺与状态。

先用一个数学视角看 Blob。协议把 4,096 个字段元素解释为某个多项式在一组固定点上的取值。KZG 允许发布者从这份多项式得到一个固定大小的承诺 C。之后，验证者可以检查“在点 z 上，值确实是 y”，而无需把整个多项式塞进证明。

承诺具有绑定性：发布者不能在同一个承诺下随意声称两个不一致的值。点证明则让局部数据能够对照承诺验证。这正是后续数据抽样所需的能力：节点只抽少量单元，也能知道收到的单元属于被区块承诺的那份数据。

假设恶意区块提议者构造了一份完整 Blob，计算出正确 KZG 承诺，却只向网络发送其中一部分。收到的片段都能通过承诺检查，因此“完整性”没问题；但缺失片段让任何人都无法重建 L2 批次，于是数据并不可用。

这就是数据可用性问题：不是问数据内容是否诚实，而是问重建所需的全部信息是否已经发布。传统做法让每个节点下载全部数据，答案直接但扩展性差。DAS 的目标，是用纠删码和随机抽样把“全量下载”改成“高置信度检查”。

PeerDAS 先把每个 Blob 经过 Reed-Solomon 风格的纠删码扩展，相当于增加可恢复冗余；再把扩展后的数据切成可独立验证的 cells，并按跨 Blob 的相同位置组成 128 列。节点不再永久接收每一列，而是根据节点身份和验证者余额承担一组列的托管责任。

一个普通非验证节点至少托管 4 列；每个 slot 的可用性检查至少抽样 8 列。连接验证者的节点至少托管 8 列，并随总有效余额增加托管列数；达到 4,096 ETH 阈值的节点成为托管全部 128 列的 supernode。取得至少 64 列即可重建扩展数据。这里的“托管”是持续保存与服务责任，“抽样”是对当前区块可用性的主动检查，不要混为一谈。

节点从相应 gossip subnet 或对等节点取得列；验证 cell 证明，确认它们与区块里的 KZG 承诺一致；若缺失则主动向其他 peers 请求。纠删码带来的冗余意味着网络只要保有足够列，就能重建并“修复”缺口。大量节点以随机身份覆盖列，使攻击者很难只对所有诚实抽样者隐藏同一关键部分。

最终的安全不是“某个节点抽了 8 列，所以必然完整”，而是纠删码阈值、随机托管分布、对等发现、请求重试、验证者投票规则和足够多独立参与者共同形成的概率与共识保证。

早期以太坊分片构想包含多条各自执行交易的 shard chains。Rollup 发展得更快后，路线改变了：L2 负责扩展执行，L1 专注安全结算和大规模数据可用性。Danksharding 因此是 data sharding，不是把账户和合约拆散到许多彼此通信的执行链。

“Dank” 来自研究者 Dankrad Feist 的名字。它的关键设计直觉是：一个区块提议者选择整个数据集合，而不是每个分片各有一个提议者；Blob 使用统一费用市场，数据在逻辑上形成一个大矩阵，再由纠删码与数据可用性采样让网络共同确认。

数据容量越大，构建完整区块越需要带宽和专门基础设施。如果要求每个家庭验证者在很短时间内收集、选择和传播全部数据，去中心化会受到压力。Proposer-Builder Separation（PBS）把高资源的区块构建工作与最终提议职责拆开：专业构建者准备区块，随机选出的提议者选择并签名。

今天以太坊已有依赖 MEV-Boost 的协议外 PBS 实践，但协议内 ePBS 仍未上线。完整 Danksharding 与 ePBS 在路线图上高度相关，因为构建者可能处理大数据块，而普通验证者通过 DAS 验证可用性；这仍是一项需要协议设计、审查和客户端实现的未来工作。

设想爱丽丝声称：“我知道一个数 x，满足 x² = 9。”最直接的验证方式，是让她公开 x，你重新平方。零知识证明追求更强的形式：爱丽丝给出证明，让你确信她知道满足关系的见证，却不必泄露见证本身。

区块链扩容把这个框架推广到一整批计算。公开声明可以是“旧状态根 S₀ 按这套程序和公开输入执行后得到新状态根 S₁”；私有或庞大的见证则包含交易、签名、账户路径和所有中间执行轨迹。证明者把见证代入约束系统，生成证明 π；L1 验证器只检查公开输入和 π。

在 ZK Rollup 里，工程上最重要的往往是 validity 和 succinctness：证明一个巨大状态转换有效，并让 L1 低成本验证。许多 Rollup 为了数据可用性，会公开足以重建状态的交易数据，所以地址、金额或调用并不天然隐私。

更准确的说法是“使用零知识证明技术的有效性 Rollup”。同一种证明系统可以用于隐私应用，也可以用于完全公开的执行压缩；是否隐私取决于哪些输入被隐藏、哪些信息必须发布，而不是项目名称里有没有 ZK。

说“以太坊会用 ZK”太宽泛。你必须追问：谁在证明什么？谁验证？数据放在哪里？证明失败或证明者离线时会怎样？同一种数学工具，放在不同协议层，会改变完全不同的成本和信任边界。

L2 zkEVM 在另一条 Rollup 状态机上执行 EVM 风格程序，向以太坊上的验证器合约提交有效性证明。以太坊 L1 仍照常由所有验证者执行和验证自己的区块。

L1 zkEVM 的远期目标则是为以太坊主网区块本身生成 Type-1 等价执行证明。若进入协议，验证者可能从“每个人重执行完整区块”转向“少数证明者计算、所有人快速验证”。这对提高 L1 Gas 容量、轻客户端和更小验证硬件有潜在意义，但实时证明、soundness、安全位数、证明大小、递归、客户端多样性与故障回退都必须成熟。

假设 100 个批次各有一个证明。直接在 L1 验证 100 次仍然昂贵。递归证明可以把“这 100 个证明都有效”本身变成一个新证明；更高层再聚合多个 Rollup 的证明。验证成本因此可以多层摊销。

但递归只压缩验证，不会自动发布底层数据。即便一个超级聚合证明完美证明一百万笔交易都算对了，用户仍需要数据来知道自己的余额、构造状态证明、运行节点并在运营者失灵时继续系统。

现在可以读懂一笔 ZK Rollup 批次的完整路径：L2 执行交易，形成新状态根与执行见证；压缩后的状态重建数据放入 Blob；KZG 把 Blob 绑定到区块；PeerDAS 让验证者确认数据可用；证明者从执行轨迹生成有效性证明；L1 验证器确认状态转换，最终接受新状态根。

这不是一个证明，而是两类保证共同工作：一类来自共识网络对数据可用性的概率与经济保证；另一类来自密码学证明对计算关系的可靠性保证。只满足其中一类，系统仍可能失去 Rollup 应有的安全属性。