一笔 Cosmos 交易在真正改动任何状态之前，要先跑完一串检查：签名对不对、序号是不是下一个、手续费够不够、扣完之后该给多高优先级。这串检查在 Cosmos SDK 里叫 AnteHandler，由若干”装饰器”顺序串起来，任何一道过不去，交易就被退回，用户连执行的门都摸不到。很多”交易广播了却查不到”的困惑，答案就在这条前置链上而不是在合约里。
一条装饰器组成的流水线
AnteHandler 的形态是一个链：每个装饰器拿到上下文和交易，自己判断，判过了就交给下一道，判不过就直接返回错误。SDK 的 x/auth/ante 包负责把这套东西装配起来，官方注释把它的职责写得很直白：检查并递增序号、检查签名与账户编号、从第一个签名者那里扣除手续费。
常见的几道闸各有分工。有一道做交易级基本校验，例如备忘录长度上限、是否设置了有效的超时高度（超过某个区块高度或时间点就不再有效的交易直接无效）。有一道管身份：把签名与被签内容对上，同时核对账户编号与序号——序号是每账户单调递增的计数器，用掉一次加一，这是同一地址防重放的关键；重放旧交易、多设备并发提交时撞上未确认的前一笔，往往报的就是这一道。还有一道管钱：解析费用、检查 gas 上限是否为正、按链上参数算出有效费用并从账户扣下。
优先级是从费用检查里长出来的
值得单独说的是优先级。SDK 把”这笔交易该排多前”交给一个可注入的 TxFeeChecker 函数：它同时返回两样东西——后面真正要扣的有效费用，以及一个优先级数值，后者会被放进上下文，最终出现在 ABCI 响应里，供出块者在组装区块时排序。也就是说，在 Cosmos 系链上，“加价插队”这件事的实现位置不是共识算法，而是这条前置链里的费用闸；具体怎么算优先级、用哪种 denom 折算，由链的实现决定，不在 SDK 里写死。
官方对这条链的动机还有一句关键说明：这套校验特意跑在 CheckTx 阶段，目的是防刷和防拒绝服务。因为同一笔交易在进入区块执行时会被重新走一遍完整校验（尤其在 EVM 兼容链上，EVM 自己也会做同样的检查），在入池前先廉价筛一遍，就不必为垃圾交易支付执行成本。这也解释了为什么入池成功不等于最终上链——入池靠的是 CheckTx 的视图，执行时状态可能已经变了，序号被别的交易抢先推进就是典型情形。
出错位置决定排查方向
对使用者来说，把这条链当作一张排查表最省事。交易在 RPC 广播时就被拒，通常报错能指出是哪道闸：签名验证不通过、序号过旧或过新、账户没有余额付手续费、gas 为零（实现里会明确拒绝”必须提供正的 gas”）、备忘录太长、超时高度已经过了。已经入池但迟迟不进块，则更可能是优先级排不上或被后来的交易挤掉，而不是前置校验的问题。
还有一件事必须说清楚：AnteHandler 是可装配的。链的应用方通过 SetAnteHandler 决定顺序、替换某些装饰器、追加自定义的准入检查，比如要求交易携带某种扩展字段、限制某类消息只在特定阶段出现。同一条”这笔交易被拒了”的现象，在两条不同的 Cosmos 链上成因可能完全不同。查具体某条链时，应当看它应用仓库里装配 AnteHandler 的那段代码和该链文档，而不是套用别的链的经验。
广播方式也会影响你看到错误的位置。同步广播会等节点把交易送进执行流水线后再返回结果，前置校验的失败能立刻反映在响应里；异步广播只要节点收下单子就返回，校验失败要靠后续查交易才暴露。钱包与节点脚本在”提交了却查无此单”时，先确认当时用的是哪种广播，再决定是去 RPC 响应日志里找被拒原因，还是去按哈希查询执行结果。序号冲突的安全重试方式是等前一笔落块后基于新区号重新构造签名，而不是把同一份已签名的字节原样重发——后者的签名内容没变，只会再次撞在同一道序号闸上。
本文描述的是 SDK 的通用结构与官方实现中的职责划分，参数默认值与各链的实际顺序以官方文档和源码为准。本文是协议机制解释，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。