zkSync 的一笔二层交易，为什么钱主要花在 pubdata 上

一条二层交易的钱，花在了哪

很多人以为把交易搬到二层，费用就只跟”这条链算得多复杂”有关。对 ZK Rollup 来说，更主导的一笔账其实是 pubdata。按 ZKsync 官方文档的说法，pubdata 是每条 L2 交易都必须发布到以太坊上、以便 L1 能重建和验证状态的那份数据。ZK Rollup 靠有效性证明保证状态正确，证明本身在 L1 验证的开销相对固定，真正随你的行为变化、还常常是主导项的，是要塞进 L1 的那份数据有多大。看懂一笔 zkSync 交易的费用，绕不开先问：它往 L1 发了多少 pubdata。

pubdata 里装的是什么，为什么必须上链

粗略地想，让 L1 在不重跑全部执行的前提下能核对状态，需要三类东西：交易的必要输入、状态从旧值到新值的变化（存储 diff）、以及验证签名等会被证明系统消费的数据。这些被压缩后合在一起，就是要发布上 L1 的 pubdata。它不能省，是因为一旦这份数据不可得，别人就无法从 L1 出发重建这条链、也无法在排序器不作恶时自己算出新状态。执行可以在链下做，pubdata 却必须回到那条被信任的链上。于是 L2 费用的一种朴素拆解是：二层执行 gas 加上”折算这份 pubdata 要花的 L1 成本”。文档在讲费用模型时正是把 gas 用量与 pubdata 占用合起来计费——一笔交易的 gas 价会同时反映执行和它占用的 pubdata 字节。

压缩与每字节单价，决定了同类操作差价

同样是转账，为什么有人贵有人便宜？一部分答案在压缩。pubdata 可以压缩后再发布，压缩后的字节要付的等效 gas 比未压缩的低，所以能被高效压缩的状态变化更省。另一些操作天生”数据重”：往链上写较大的字节、部署新合约、批量改很多互不相关的存储槽，都会把 pubdata 推高，从而把这笔 L2 交易变贵；反过来，只动少量已存在存储的简单调用更省。这也解释了为什么 ZK Rollup 的费用对”字节数”比对”计算量”更敏感——这跟以执行为主成本的传统链直觉相反。具体的每字节 gas 系数和压缩折扣是版本参数，会随升级调整，以官方文档当前口径为准，别把它当成固定数字记死。

坎昆之后，pubdata 挪进了 blob

以太坊在 Dencun 升级引入 proto-danksharding（EIP-4844）后，Rollup 可以把数据发到一种更便宜的临时数据载体 blob 上，而不必挤进昂贵的 calldata。ZKsync 官方文档专门有”4844 之后的 pubdata”一节描述这次变化：批次发布方式改了，per-pubdata 的计费口径随之调整，把 blob 占用折算进 L2 交易成本。对用户最直观的体现，是同一笔操作的 L2 费用随 L1 的 blob 市场松紧而波动——blob 需求高时、折算进 pubdata 的成本就贵，闲时便宜。这也是为什么你会看到二层手续费不是常数，而是跟着一层的 blob 基础费起伏。

把 pubdata 挪出 L1，省了钱也换了信任

正因为 pubdata 上 L1 是主要成本，一条省费的路子就是”别把它全放 L1”。在 Validium 模式下，链仍然用有效性证明确保状态正确，但把 pubdata 发布到一个数据可用性委员会（DAC）而非以太坊上，费用因此明显下降；代价是数据可得性的信任从以太坊转到了那个委员会——它若集体不作恶又不给数据，状态就难以重建，提款可能受阻。ZKsync 的 Volition 模式更细，允许逐笔交易在”上 L1 的 Rollup”和”上 DAC 的 Validium”之间切换，把选择权交给发起方。看懂这一层，就能理解为什么”同为 ZK Rollup，费用和安全等级并不相同”：真正区分安全预算的，是 pubdata 到底由谁保证可得。

从链上怎么核这笔账

作为读者，与其听项目方说”便宜”，不如自己把两笔同类操作的账单摆在一起看：在区块浏览器或费用估算接口里，同一笔转账在数据量小的调用和含大额存储写入的调用上，gas 用量往往差出一个量级，这个差额更多来自 pubdata 占用而不是执行步数。再对照一层上当时的 blob 基础费——它高企的那几天，二层同类操作的折算费用通常也水涨船高。把这两组可复核的数字对齐，就能判断一次涨价到底是”这条链变贵了”还是”一层的临时数据空间紧了”，而不会被单点报价带着走。要注意同名资产在不同网络上的浏览器地址并不通用，核对时先确认查的是哪条链。

风险提示：本文为费用与数据可用性机制说明，不构成投资建议；per-pubdata 系数、压缩折扣、blob 折算口径随协议与以太坊升级调整，涉及资产操作请以 ZKsync 官方文档为准。