签好的交易 150 个时隙就作废？Solana 区块哈希时效与 durable nonce

一笔签好名的交易，是有保质期的

在 Solana 上广播一笔延迟提交的交易，最常撞到的报错是 blockhash 找不到。原因写在官方交易文档的限制清单里：每笔交易都要携带一个近期区块哈希（recent blockhash），验证者检查它是否还留在近期的区块哈希队列里，超过 150 个时隙窗口即拒绝执行。这个字段不是用来省事的，它是交易的寿命证明：带上”我在什么时候的世界状态下签的名”，节点据此挡掉太久远的陈旧交易和重放，顺便让卡在半路的交易自然过期，不需要额外的撤销机制。世界状态约每 0.4 秒一个时隙地翻篇，一笔交易的保质期因此只有很短的一段窗口。

设计取舍也很清楚：在线钱包、普通转账在窗口内轻松完成，但离线签名、多方会签、国库审批这类”先签后交”的流程很容易在窗口边缘翻车——签名者断网一天，交易在技术上完好无损，在链上已经死亡。

Durable nonce：把哈希换成一枚不会过期的章

官方文档给出的解法叫持久随机数（durable nonce）：交易里的近期区块哈希换成某个 nonce 账户里存储的值，150 时隙的过期窗口随之取消，签名与提交的时间差被完全拉开放大。规则的关键在执行前那一步：使用 durable nonce 的交易，第一条指令必须是系统程序推进该账户的调用，nonce 账户要列在该指令的第一个账户且可写；验证者按当前区块哈希推出这个账户的下一个值，确认账户里存的不是那个”下一个值”、账户处于已初始化状态且值与交易携带值一致，再把账户推进到新值，然后才开始执行其余指令。一个值只能用一次，用即推进——它防的不是别人伪造，而是同一份已签交易被提交两遍。重放防护从”时效窗口自然淘汰”换成了”一次性凭据即刻作废”，信任点从区块哈希队列转移到这个账户的状态上。

要如实转述官方页面的另一条注记：durable nonce 在文档中明确标注未来版本可能弃用，并指向 SIMD 的讨论。把延迟提交流程建在它上面是可行的，但属于需要跟踪进度的依赖，不是可以忘掉的地基。

排障与边界：先分清寿命机制，再谈失败原因

交易迟迟不上链，第一步是分辨它用的是哪种寿命机制。走近期区块哈希的，查签名时的哈希距今是否越出 150 时隙、客户端取哈希与广播之间是否拖太久；走 nonce 的，查那个 nonce 账户的当前值——如果它已被别的交易推进过，所有还挂着旧值的已签交易同时作废，这是共用 nonce 账户时最常见的事故：两笔离线会签的交易先后构造，先提交的那笔把当前值推进掉，后一份已签交易里的旧值就变成废票。账户状态、推进指令位置、权限签名三者任一不符，节点都会以失败交易的形式拒绝入账。

再划三条边界。其一，durable nonce 不改变费用机制，也没有豁免状态冲突：手续费仍按交易上的签名数量计算，换成 nonce 提交不会多收或少收；引用账户的当前状态变了，交易照样执行失败，“不会过期”只解决时间维度。其二，nonce 本身不授权，谁有权推进账户由账户权限字段决定，托管或多签流程通常把推进权交给提交方、把所有权留在审批方，两个角色分开配置是常见防御；反过来，把推进权留在自己手里而提交权外包，等于让提交方无法用别的交易烧掉你的 nonce，两种分工各有适用场景。其三，窗口参数与机制存续都可能随升级调整，官方页面已经写明 durable nonce 可能在未来版本弃用并附上了社区讨论入口，引用细节以官方文档当时的版本为准。交易结构与字段的逐项拆解参见 Solana 交易是怎么组装的？签名、消息与指令表的 1232 字节。本文为机制说明，不构成任何投资建议。