一笔 Starknet 交易的回执上其实挂着两个状态字段：执行状态和终局状态。很多人只盯着其中一个，就会把”节点收到了”误读成”链上定局了”。官方文档自 0.14.0 版本起把终局状态拆成六个层级，每一层的可信程度和可撤销条件都不一样。本文按官方交易文档逐层拆解这套状态机，以及失败交易为什么照样扣钱。
交易先经过哪些环节
按 Starknet 文档的交易生命周期，一笔交易从提交到进入以太坊要走过五步：全节点把交易提交给排序器；排序器的内存池先做初步校验，例如检查发起账户的余额是否覆盖交易声明的费用上限、调用数据长度是否合规；排序器在打包前再校验一次；通过校验的交易被批量组入区块、顺序执行，执行失败的交易也会被写进区块，只是标记为反转；最后证明者借助 Starknet 操作系统计算整个区块的执行证明，送到 L1 的验证合约校验，通过后以太坊上的状态才更新。
关于内存池，文档给出了 0.14.0 起的几条规则：交易可被同一账户、相同 nonce 的新交易顶替，条件是小额费（tip）和 L2 燃气单价同时上调至少一成；在池里太久进不了块的交易会按存活时间被逐出，文档记载当前配置为五分钟。这些规则解释了为什么你加速后旧的那笔会从节点视野里消失——它不是被”取消”了，而是被替换了。
六级终局各自说明什么
文档列出的终局状态依次是：NOT_RECEIVED，任何排序器都还不知道这笔交易；RECEIVED，有全节点成功把它递给了某个排序器，但节点之间没有互相广播交易状态的对等协议，所以换一个节点查询可能直接报”哈希不存在”，依赖这一层状态需要与你提交的节点保持会话粘滞；CANDIDATE，排序器已把交易哈希写进数据网关的存储，但尚未执行，因此没有任何执行信息；PRE_CONFIRMED，排序器执行完毕、回执已写入数据网关；ACCEPTED_ON_L2，交易被包含进一个经共识协议最终确认的区块；ACCEPTED_ON_L1，以太坊上的 Starknet 状态已经推进到不低于该交易所在区块的高度。
执行状态则只有两个值：SUCCEEDED 与 REVERTED。两者与终局状态正交——一笔被反转的交易同样可以 ACCEPTED_ON_L1，它确实进了块、确实花了钱，只是效果被撤了。
反转交易为什么还收费
文档对 REVERTED 的约定值得逐条看。第一，账户 nonce 照常递增，失败不会把序号退回去，这也是重发必须重新构造交易而不是原样再签一次的原因。第二，排序器按执行到失败点为止消耗的资源收费，并发出相应的转账事件；费用取”用户愿意支付的额度”与”实际消耗资源”两者中较小的一个，消耗资源的口径包括 Cairo 步数、内建算子、系统调用、L1 消息、事件与状态差异，且校验阶段的开销也计入。第三，回滚只覆盖执行阶段：校验阶段产生的改动不回滚，执行阶段发出的 L1 消息和事件会被撤销，但校验与收费阶段的事件可能保留。对钱包和索引器来说，这意味着不能拿”有事件”当作交易全绿的证据。
对使用者意味着什么
不同业务该卡在哪一层放行，取决于回滚成本：展示”已提交”看 RECEIVED 就够，但它高度依赖单一节点的视野；展示”链上已成”至少要等 ACCEPTED_ON_L2；而要把资产变动当作对以太坊的最终事实，则应等 ACCEPTED_ON_L1。文档同时提醒，交易版本也有支持窗口——INVOKE、DECLARE、DEPLOY_ACCOUNT 当前都是 v3，只支持旧版本的交易无法进入证明、也就无法进块。这类版本边界同样应当被钱包在做兼容检查时覆盖。涉及资产的确认策略调整只是风险控制手段，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。