Layer2 的状态根是怎么推导出来的？从区块数据到断言的四步链条

结论先说

一条 Rollup 被称作「rollup」的技术前提，不是它用了某一种证明算法，而是它的状态可以从以太坊 L1 的数据推导出来：L1 上的数据加上一个明确的执行规则，任何人跑一遍推导程序，都应得到和官方节点一模一样的状态根。这条从数据到状态根的链条通常分四步——取数、定序、执行、承诺。各角色谁排序、谁发数据、谁断言的分工见Rollup 的四大角色：谁排序、谁发数据、谁断言、谁证明，本文专注链条本身怎么转。

第一步取数：状态的全部原料都在 L1

推导程序的原料只有一种：L1 上按区块高度排列的输入序列。里面混着两类东西，一类是用户直接从 L1 发起的存款和消息（包括排序器失职时由任何人代为提交的强制交易，见强制交易是什么？排序器不打包时如何绕过它上链），另一类是排序器定期发布的数据批次——Optimistic Rollup 时代常是 calldata，如今多为 blob。关键点在于完整性：只要 L1 数据拿全，L2 每一笔交易、每一次转账都必然在里面，没有第二本账。

第二步定序：顺序本身就是状态的一部分

同一些交易换个顺序，状态根就完全不同，所以推导程序必须把「谁有权定义顺序」写成规则：正常时期按排序器批次声明的顺序执行；跨链存款按 L1 区块号和消息队列位置插入；强制交易按协议规定的入队规则排入。换句话说，L2 的共识不是独立的第二套共识，而是「L1 数据加排序规则的函数」。这也解释了一个常见误解：你从交易所提到 L2 的钱「卡在队列里」时，钱并没有丢——它已经躺在 L1 的输入序列里，任何推导程序都会在同一位置把它算进同一状态。

第三步执行：确定性重放，不靠服务器记忆

定好序列后，执行引擎从某个已确认的起点开始逐笔重放：对 EVM 类 Rollup 就是一台与以太坊规则一致的虚拟机，跑同样的指令、同样的费用规则、同样的状态修改。程序不查询任何链下缓存、不读任何非确定性的时间戳——否则两台机器会跑出两个结果。执行过程中每笔交易触发的账户变更持续更新一棵状态树；重放到序列末尾，树根就是这一状态点的状态根。若某个批次描述的交易与已确认状态冲突，推导程序必须按同一规则处理成无效或跳过，保证所有诚实节点的分歧只可能来自输入数据，不可能来自程序方言。

第四步承诺：状态根上链，证明系统兜底

推导出的状态根由提案者连同批次引用提交到 L1 合约，欺诈证明或有效性证明再对这份断言盖章：前者在挑战窗口内允许任何人用二分博弈指出某一步执行错误（机制见OP 故障博弈游戏：二分法怎么把一场争议压到一条指令），后者要求提案者随断言附上密码学证明，验证合约只认证明过关的根，两条路线的对比见ZK 证明和欺诈证明有何区别？Rollup 两种安全模型。无论哪种，被最终接受的根都必须能对应到某一段确定的 L1 输入——这正是「状态可推导」四个字的审计含义：用户随时可以自己重算，而不必信任任何一台服务器。

这条链的两种塌法

一种是数据不全：L1 数据缺失或被扣留时推导中断，这时防线在数据可用性层，Rollup 依赖委员会或外部 DA 层的路线见L2 数据可用性三条路线：回 L1、托委员会、留在手里。另一种是断言错位：错误状态根被写入合约，防线才轮到证明系统与升级机制。日常关心自己的资产在 Layer2 上是否「算对了」，本质就是问：数据在不在 L1、推导软件是否开源、断言由谁验证。三个问题都有肯定答案时，你信任的是程序；有任何一个没有时，你信任的是某个组织。本文为机制说明，不构成投资建议。