乐观汇总的默认剧本是”先信后查”：排序器把一批交易的状态根提交到 L1，挑战窗口内没人开口，这份状态就当作真。可一旦挑战者与排序器各自咬定一个结果，链上合约怎么裁？OP Stack 的答案不是一笔”把整批重算一遍”的天价交易，而是一局在链上展开的交互式对局：FaultDisputeGame 合约把双方主张铺成一棵位置树，靠反复二分把分歧从整个输出根一路折到某一步具体指令，再只对那一步做判定。整套裁决不靠信任任何一方，靠的是”错的一方总要多走一步、多押一层保证金”的结构。
主张、位置与有向无环图：棋盘先摆清楚
对局开局，一个根主张立在树顶，内容是某段 L2 输出根与提出者的立场。此后每一步落子都挂在某条已有主张之下：要么防御——在同一位置续说父主张的细化，要么反驳——在兄弟位置主张另一个值。每条主张记录父节点序号、位置、出主张者、已锁保证金与棋钟，全部存进一张只追加的 claimData 数组，父子指针自然连成一张有向无环图。合约在构造时就钉死两条边界：MAX_GAME_DEPTH 限定整棵树的深度上限，SPLIT_DEPTH 规定从哪一层往下，棋盘从”折输出”换成”折执行”——校验逻辑保证这个分界层不会贴着树顶或树底，两段棋盘衔接得上。
两段二分：先折输出，再折指令
上半段棋局折的是输出根：双方对相邻两个已确认输出之间的中间状态不断折半声明，谁的中间断言在重放里对不上，谁的整条分支就在逻辑上死掉，层数由位置树深度天然封顶。越过 SPLIT_DEPTH 后棋盘换轨成执行轨迹二分——落子坐标从”哪笔交易之后”细化成”哪个时钟周期、哪条指令之后”，一路折到相邻两步之间，链上只需对那一步做单步判定。这最后一步要靠重放程序：挑战者把本地重放该步所需的输入分片交给预镜像预言机核验哈希，链上步进机据此判断这一步的前后状态谁对谁错。值得留意的是，合约还留了一扇门：根主张声称的 L2 区块号本身可被单独质询——任何人提交区块头预镜像，只要解出的高度与声称值对不上，challengeRootL2Block 就登记一个特殊反击，按合约注释它会稳赢根主张的子对局并取走提出方的押金，整局无须再往指令层折下去。整局对下来，重执行的开销从”整批交易”压到”一条指令”，这是交互式故障证明省钱的关键，也是它要求挑战者必须真跑一份 L2 节点的原因。
棋钟与阶梯保证金：把拖延标上价格
对局给双方各挂一只象棋钟：一方落子消耗自己钟面，累计用完 MAX_CLOCK_DURATION 就失去回应资格，再也不会替它自动续钟；到了执行轨迹分界层，每次行动还能按 CLOCK_EXTENSION 给钟面续一段，分界处的续时还会加倍，防止守株待兔式的最后一刻拖延。押金则是另一根杠杆：同一文件按位置深度计算保证金需求，按注释写明的取值口径，所需 gas 随深度以固定底数逐层放大，折算的保证金随之攀升——越接近叶子，用假主张续命的成本越贵。合约里的信用账本分普通与退款两套映射，赢家份额先进未领信用，由参与者自行申领，合约不替所有人自动转账。对局终结后，合约按结果把押金转入未领信用或按分发模式退还，失败一方的锁仓成为赢家的补偿。对普通用户，这一整套只兑现成一个核验点：提款窗口内去看那一局对局的最终状态字段，而不是任何人的论坛宣言。（风险提示：本文仅说明协议机制，不构成投资建议；二层与跨链资产请以官方合约地址与文档核验，勿依赖第三方宣称。）
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。