主网上的验证合约在做什么？ZK Rollup 证明提交与验证 gas 拆解

在 ZK 二层链的架构里，主网端的验证合约是真正“说了算”的那段代码：状态能不能前进、你的余额算不算数，最终取决于它是否接受了这一轮证明。它做的事情比想象中窄，但正因为它窄，主网才能用固定的一小笔 gas 给成千上万笔 L2 交易盖章。

合约拿到的是承诺加证明，不是交易清单

一轮典型流程是这样的：L2 侧先把一批交易执行完，算出新的状态根，并把交易数据发布到主网；随后证明生成方对“从旧状态根到新状态根”的这段计算轨迹生成一个密码学证明，连同公共输入一起提交给主网合约。公共输入是双方都必须一致的那几个值，通常包括批次哈希、旧的与新的状态根、有时还包括时间或序列号。

主网合约拿到的信息量很小。它不会重放你的转账，也看不到金额，只做三件事：检查提交的公共输入是否和它自己记录的状态接得上；调用证明验证逻辑确认这份证明在当前曲线和参数下有效；通过则把状态根更新到新值。任何一环对不上，整个提交被拒，状态保持不动。

gas 账：为什么这一层的费用不随交易量涨

这里有一条和乐观方案不同的结构特点：验证一份证明的主网 gas 消耗基本是固定的，或者说只随证明大小轻微变化，而和这批证明覆盖了多少笔交易关系不大。于是把更多交易塞进一个批次、或者把多个批次的证明折叠成一个再提交（常叫聚合或递归证明），主网验证费就被更大分母摊薄。二层交易费里那部分“L1 验证费”的摊派，逻辑就来自这里。

与之对照，乐观方案在提交阶段不做昂贵验证，把成本推到挑战期与挑战者身上；如果发生争议，链上交互的开销才出现。两种设计没有绝对优劣，只是一个把成本平均分给所有人，另一个把成本条件化地交给少数参与者与时间。

谁来跑证明，卡住了会怎样

提交批次与提交证明通常是两个角色：前者负责把数据发到 L1，后者负责生成并提交证明。很多链早期由运营方自己兼任，后来才引入证明市场或证明网络，让多个证明方竞争或轮换。角色分离的意义在于，即使某一方短时故障，另一种机制仍可能补位。

要判断是否卡住，可以在主网浏览器上查该链的 Rollup 或验证合约地址，看它近期被谁调用、调用的方法名、每次消耗的 gas 与是否成功；再看 L2 上最新批次序号与 L1 上最新被接受批次序号之间有没有持续拉开。如果批次一直在发、证明一直不上，通常是证明流水线出问题；两者都不动，则是数据发布停滞。这两件事在用户侧的表现都是“提款延迟”，但等待的对象完全不同。还有一类更隐蔽的情形：证明提交交易本身成功了，但因为公共输入与合约记录对不上而内部回滚，在浏览器里表现为状态“成功”却带失败标记的事件，或者没有任何状态更新事件。看到这种组合时，不要简单归因为拥堵，而应对照该链状态页与公告确认是否为版本或参数变更所致。

还要提醒一个容易混淆的边界：验证合约证明的是“状态转换符合规则”，不是“这套规则永不改变”。合约本身可能被升级，证明系统也可能换路线，这些变更的权限与流程要看该链的治理设计，与密码学保证是两码事。

本文只做机制与链上查询说明，不构成投资建议，也不对任何链的安全性作出承诺。合约地址、方法命名与证明机制会随版本变化，以该链官方文档与链上当前状态为准。