一笔证明装多少个区块：Linea 的 conflation 分组与模块上限

一个区块一个证明，贵在哪

ZK 二层要为”状态从 A 到 B 的每一步都算对了”生成证明。如果按以太坊”一区块一批交易”的节奏逐块出证明，每个区块都要走一遍电路约束、证明生成和一层验证，固定开销被区块边界切碎。Linea 官方文档给出的解法叫 conflation：把两个或更多区块的交易合成一个数据集，当作一个批次来证明。批次与批次的边界，从此不按区块划，而按”一份证明还能不能装得下”来划。这里还有个名词分层：支撑 Linea 主网的开源协议栈已更名为 Lineth，公开网络上看到的排序、批次与证明流程都由这套栈驱动。

从区块流到批次流

文档把流程拆成四步。序批者为每个区块执行交易的同时，协调器向追踪器索取该区块的执行追踪计数；只要加上下一个区块仍不超过各项上限，就继续往里装；装不下了，或撞到预设边界，这一批就封口——能触发封口的条件在文档里逐项列出：执行追踪行数上限、压缩后数据体积上限、单批区块数上限、时间截止线，以及必须切开的事件边界，比如网络升级或强制交易。封口之后，追踪器把这一区间里的区块重放一遍，写成一份合并的追踪文件，状态树更新与 ZK 证明都基于它生成——一笔证明对应整段执行历史。

值得留意的是职责切分：生成追踪需要执行客户端在场，这一步跑在 Linea Besu 里；但”在哪切一刀”的决策权在协调器。这正是”按证明容量切分工作”的含义——批是证明经济的产物，不是时间的产物。

模块上限：批容量的物理约束

真正卡住批次大小的，是证明侧的算术化结构。Lineth 的算术化规格按模块拆分，每个模块负责一组 EVM 操作的约束：处理交易数据、管理虚拟机内存、协调模块间交互，各有各的”最多生成多少行数据”的额度，参数在源码仓库的配置文件中公开可查。文档里有个反直觉的细节：同一操作被相同参数重复调用不产生新行，只有新的参数组合才生成新行——这意味着同样尺寸的两笔交易，在不同时刻面对的剩余额度并不相同。一条高复杂度交易可能触破某个模块的行数上限，序批者为了把送入证明器的追踪控制在可生成范围内，会直接拒绝它。

没进块的交易，按三层顺序查

遇到交易长时间不落地，可以用文档给出的方法逐层排除信号。入口层，linea_estimateGas 与 eth_sendRawTransaction 对会被拒绝的交易直接返回错误；灰区层，一笔交易既没有被入口报错、又没有进块，可以用 linea_getTransactionExclusionStatusV1 按交易哈希查询被排除的状态，文档限定这类查询适用于 RPC 节点与序批者执行结果不一致的边缘场景；参数层，模块上限清单以版本化配置文件发布，规格随版本演进，排查前应先确认自己对照的是哪一个版本，不同版本的上限可能已经变化。

再往深处，还有一层容易被省略的分层事实：交易进二层块（软终局）、覆盖它的批次被打包提交、证明在以太坊上通过验证并被共识终局（硬终局），是三件事。钱包显示”已确认”只说明第一件；跨层提款或对不可逆性敏感的场景，需要核对后两件——用 JSON-RPC 的 finalized 标签查询硬终局区块，或读取一层 Rollup 合约的 currentL2BlockNumber。文档同时提醒了读取口径：区块浏览器展示的是最新一层区块里的合约状态，可能比真实硬终局位置略靠前，精确判断应以 finalized 标签为准。

批不是区块、确认不等于终局、上限随版本移动——这三条边界，构成了在这类 ZK 二层上核验一笔交易时的基本坐标系。本文为机制解释，不构成投资建议。