持久 Nonce

什么是持久 Nonce？

持久 Nonce 是存储在 Solana 特殊账户中的持久值，可让交易在通常的近期区块哈希过期时间之后继续有效。标准 Solana 交易包含近期区块哈希，其有效期仅为 150 个 Slot。如果交易未能在近期区块哈希过期前得到处理，通常就无法使用同一条已签名消息再次成功提交。持久 Nonce 会用存储的值替代短期有效的区块哈希，直到 Nonce 账户被推进或以其他方式更改，该值才会失效。因此，持久 Nonce 适用于离线签名、延迟提交交易、多方审批、冷存储操作、计划工作流，以及签名者无法在短时间内批准交易的组织。

Solana 官方持久 Nonce 文档说明，该机制使用存储在链上账户中的 Nonce 值，取消了标准的 150 Slot 过期窗口。

持久 Nonce 并不能保证交易在所有情况下永久有效。如果存储的 Nonce 发生变化、Nonce 账户被关闭、所需权限发生变化，或另一笔交易成功使用了相同的 Nonce 值，该交易就会失效。

Solana 交易通常为何会过期

标准 Solana 交易包含名为

的字段。

区块哈希是一个有时效的引用，用于证明交易是在近期创建的。它还有助于防止已处理的交易被重复提交。验证者会将交易中的区块哈希与网络近期区块哈希队列进行比对。

当前的Solana 交易处理流程规定，普通区块哈希只有在其年龄不超过 150 Slot 的最大处理年龄时才会被接受。

区块哈希过期后，验证者会在执行交易指令前拒绝该交易。这种过期机制可以防止无限期重放，并限制验证者必须将普通已签名交易视为可能可执行状态的时间。如果签名所需时间超过区块哈希的有效期，这一限制就会带来问题。

为何需要持久 Nonce

有些加密货币交易无法在短暂的在线会话中完成创建、审批和提交。公司可能要求多个国家的员工共同签署交易。财库可能将签名密钥保存在永不直接连接互联网的气隙计算机中。高安全级别的操作可能要求交易在广播前经过技术、财务和合规审查。多重签名工作流可能要求多个硬件设备在不同时间为同一笔交易签名。支付应用可能在一个运营时段内准备交易，并在稍后提交。使用普通近期区块哈希时，每当区块哈希过期，都需要重新构建并签署完整消息。持久 Nonce 允许各方为一条稳定的交易消息签名，并在标准区块哈希有效期结束后提交交易。

什么是 Nonce 账户？

Nonce 账户是由 System Program 所有的 Solana 特殊账户。该账户存储用于支持持久 Nonce 交易的状态。已初始化的 Nonce 账户包含权限公钥、持久 Nonce 值，以及上次推进 Nonce 时记录的每个签名所需 lamports 手续费率。权限账户指定了获准推进、重新授权或从 Nonce 账户提取资金的账户。持久 Nonce 值是根据近期区块哈希派生并存储起来、供之后使用的哈希值。与手续费相关的值则保留手续费处理流程所需的信息。Nonce 账户在保持活跃期间必须持有足够的 SOL，以满足适用的免租金要求。应用应向网络查询当前最低余额，而不要永久写死估算金额。

持久 Nonce 与近期区块哈希

近期区块哈希是在签署普通交易前不久从网络获取的。它会在网络有限的处理窗口后过期。持久 Nonce 存储在链上账户中，即使其派生所依据的区块哈希不再属于近期哈希，也仍然可用。普通交易不需要创建或修改 Nonce 账户。持久 Nonce 交易必须引用 Nonce 账户，并包含一条用于推进该账户的特定指令。如果用户可以及时签名并提交，通常应使用更简单的普通交易。持久 Nonce 会增加账户管理、签名、交易大小、手续费和运营方面的要求。

持久 Nonce 与账户序列号

不同加密货币系统对 Nonce 一词的用法并不相同。一些基于账户的区块链会使用递增的账户交易序号来排列交易并防止重放。Solana 持久 Nonce 并不是附加在每个钱包交易上的持续递增计数器。它是存储在专用 System Program 账户中的哈希值。

该值会放入交易的

字段，并在 Nonce 被推进时替换。

开发者不应将其他区块链中的交易计数器假设套用到 Solana Nonce 账户。

持久 Nonce 交易的运作方式

流程首先是创建并初始化 Nonce 账户。创建者指定一名权限方，以控制之后的 Nonce 操作。应用读取账户中存储的持久 Nonce 值。

应用使用该值构建交易，并将其填入交易消息的

字段。

交易会在指令列表的首位放置

指令。

所需账户会对序列化后的完整交易消息进行签名。由于存储的 Nonce 不会在 150 Slot 后过期，因此可以离线生成签名。组织准备好后，会将已签名交易传输到在线系统并提交。验证者会检查 Nonce 账户是否有效、存储值是否与交易匹配，以及 Nonce 权限方是否已签名。在执行其余交易指令之前，Nonce 会先被推进。

AdvanceNonceAccount 指令

指令用于通知 System Program 将存储的 Nonce 替换为新值。

该指令是持久 Nonce 防止重放的关键。

只有当

是第一条指令时，交易运行时才会将交易识别为持久 Nonce 交易。

Nonce 账户必须出现在要求的账户位置，并且必须可写。Nonce 权限方必须为交易签名。如果将该指令放在后面，运行时可能会把交易视为已过期的普通交易，而不是有效的持久 Nonce 交易。

官方Nonce 检测规则说明了这一首条指令要求。

Nonce 为何必须推进

持久 Nonce 值只能使用一次。如果不推进 Nonce，攻击者或意外操作就可能反复提交同一笔已签名交易。推进账户会使用当前网络状态派生的新值替换旧 Nonce。之后，任何使用旧值的其他待处理交易都会失效。因此，如果希望多笔已签名交易都能执行，通常不应让它们依赖同一个共享 Nonce 值。第一笔被接受的交易会推进账户，并使使用旧值构建的其他交易失效。多个并行的延迟工作流通常应分别使用不同的 Nonce 账户。

Nonce 权限方

Nonce 权限方是获准控制 Nonce 账户重要操作的公钥持有者。推进 Nonce 的交易必须由权限方签名。更改 Nonce 权限方也必须得到其授权。从 Nonce 账户提取资金时也需要该权限方授权。

当前的System Program Nonce 账户接口说明了这些权限要求。

权限方账户不必与交易手续费支付方相同。将这两项职责分开有助于支持组织安全政策。应妥善保护 Nonce 权限方，因为未经授权地推进 Nonce 可能会使已离线签署的交易失效。

手续费支付方与 Nonce 权限方

手续费支付方是支付交易基础手续费及任何优先费的账户。Nonce 权限方负责授权使用存储的持久 Nonce。同一个账户可以同时承担这两种角色，但两者在逻辑上相互独立。交易还可能需要资产所有者、代币权限方、程序管理员或其他账户的签名。每个必需的签名方都要为同一条交易消息签名。更改手续费支付方通常会更改消息，因此已有签名会失效，除非工作流采用了专门设计来分离这些步骤的未来格式。

离线签名

离线签名可以让私钥远离连接互联网的设备。在线系统可以收集账户信息并构建未签名的持久 Nonce 交易。然后通过受控介质或其他经过审计的流程，将序列化消息传输到离线签名设备。离线设备验证交易并生成所需签名。之后将已签名交易传回在线系统进行提交。只要 Nonce 账户没有被推进或更改，Nonce 在此过程中就会保持有效。离线签名可以减少直接的网络暴露，但无法防范恶意构建的交易。签名前，签名者必须检查目标地址、金额、程序地址、代币铸造地址、权限、手续费及所有重要指令。

多重签名与多方审批

当一笔交易需要多方签名时，持久 Nonce 会很有用。普通区块哈希可能会在消息传递给各签名方的过程中失效。使用存储的 Nonce 可以让每位签名方有更多时间检查并批准完全相同的消息。收集齐所有必需的审批后，即可汇总最终签名并广播交易。整个流程必须保留完全相同的序列化消息，因为更改任何指令、地址、手续费参数或账户标志都会使签名失效。审批期间，Nonce 账户也必须保持不变。组织应监控 Nonce 账户，以便在提交前发现意外推进或权限变更。

延迟执行

持久 Nonce 允许延迟提交，但它本身不会安排交易执行。仅仅因为交易使用了持久 Nonce，区块链就不会在指定的未来日期自动执行交易。用户、服务器、自动化系统或中继器仍须提交已签名交易。因此，提供定时付款功能的应用除了持久 Nonce 之外，还需要链下调度器或链上调度设计。提交系统应在广播前立即确认 Nonce 仍然有效。系统还应确认预期的业务条件仍然成立。

提交前交易状态可能发生变化

持久 Nonce 交易可以保持已签名状态，但其所依赖的区块链状态仍可能发生变化。账户余额可能增加或减少。代币账户可能被冻结或关闭。智能合约可能升级。预言机价格可能发生变化。治理决定可能更改程序参数。收款账户可能不再处于预期状态。交易签名能够证明签名者批准了序列化消息，但无法冻结未来执行时所涉及的所有外部账户或程序状态。如果应用支持，延迟交易应包含适当的限额、预期值、截止时间或程序级检查。

重放保护

重放保护可以防止同一组已签名指令被重复执行。普通 Solana 交易部分依赖近期区块哈希过期机制和网络已处理交易追踪。持久 Nonce 交易则依赖 Nonce 账户中的一次性存储值。验证者一旦接受并推进该值，旧的已签名消息就不再与账户匹配。因此，再次提交同一笔交易会因 Nonce 验证失败而被拒绝。这项保护依赖于正确放置推进指令，并要求 Nonce 权限方提供签名。

持久 Nonce 交易成功后会发生什么？

验证者会确认存储的 Nonce 与交易的

匹配。

验证者会检查 Nonce 账户已初始化，并由 System Program 所有。验证者会检查 Nonce 权限方是否为交易签名。运行时会将 Nonce 推进为新值。其余指令随后按顺序执行。如果所有必需指令均成功，其状态更改和已推进的 Nonce 都会一并提交。手续费会从手续费支付方账户中扣除。由于旧 Nonce 已被使用，旧交易不能再次执行。

执行失败时会发生什么？

持久 Nonce 的失败处理方式有一项重要区别，它并不符合“失败交易中的所有状态更改都会回滚”这一简化规则。如果交易通过了 Nonce 和手续费支付方验证，但后续指令失败，普通指令造成的状态更改会回滚。但 Nonce 推进仍会提交。交易手续费也仍会收取。

Solana 官方失败处理文档说明，这可以防止同一笔已签名交易被反复重放，直到某次执行成功。

因此，持久 Nonce 交易失败后仍会消耗 Nonce。用户必须获取新的 Nonce、重新构建交易并收集新的签名，才能再次尝试。

验证失败时会发生什么？

交易可能在 Nonce 被认定为有效之前就失败。可能的原因包括缺少 Nonce 账户、Nonce 已被使用、存储值与交易不匹配，或缺少权限方签名。如果在这一阶段 Nonce 验证失败，交易就会被丢弃，其指令不会执行。根据当前文档所述的行为，这类验证失败不会收取手续费，也不会提交任何状态更改。应用应识别具体错误，而不是反复广播同一笔不可用的交易。

确认与重试风险

提交应用必须判断持久 Nonce 交易是已成功处理、已处理但执行出错，还是从未被接受。如果原交易实际上已经成功，盲目重建并提交替代交易可能导致意外重复执行业务操作。在 Nonce 已被使用后盲目重发原交易也没有效果。应用应查询交易状态并检查 Nonce 账户。系统应区分交易最终性与指令执行成功。已最终确认的交易记录也可能包含执行错误。运营系统应核对预期的余额和账户变化，而不能仅凭交易签名是否存在来判断结果。

交易手续费

每笔 Solana 交易都需要以 SOL 支付手续费。

当前的Solana 手续费文档说明，基础手续费为每个签名 5,000 lamports，另可支付优先费。

持久 Nonce 交易需要 Nonce 推进指令和相关账户引用，但无法免除普通签名手续费。增加签名方会提高基础手续费。交易通过相关验证阶段后，即使执行失败，也可能消耗 Nonce 并收取手续费。应用应确保手续费支付方账户中有足够 SOL，同时 Nonce 账户也有足够资金满足免租金要求。

优先费

在网络需求较高时，优先费可以提高交易被安排处理的机会。但它不能保证交易一定被纳入区块或成功执行。持久 Nonce 交易在包含计算预算指令时有特殊的指令顺序要求。

指令必须始终位于首位。

不得将计算单元价格和限制指令放在它之前。

官方的Solana 集成指南警告，如果将计算预算指令放在首位，运行时可能无法正确识别持久 Nonce 交易。

Nonce 账户资金与免租金要求

Nonce 账户包含数据，因此在保持活跃期间必须维持网络要求的免租金余额。应根据 Nonce 账户的数据大小，通过适当的网络查询获取准确的最低余额。部分提取资金后，Nonce 账户不能留下高于零但低于免租金要求的余额。试图造成这种状态的交易会失败。成功提取全部余额会关闭 Nonce 账户。

当前的Nonce 提取接口说明了这些余额规则。

关闭 Nonce 账户

可以通过经过授权的指令提取 Nonce 账户中的全部 SOL 余额，以关闭账户。提取操作必须得到 Nonce 权限方批准。关闭账户会使所有依赖其存储 Nonce 的未提交交易失效。因此，提取全部余额前，组织应检查是否存在待处理的已签名交易。应记录哪些 Nonce 账户仍然活跃、哪些交易使用这些账户，以及哪些账户可以安全关闭。

更改 Nonce 权限方

当前 Nonce 权限方可以通过经过授权的 System Program 指令指定新的权限方。员工离职、密钥迁移、托管政策变更或安全事件发生后，都可能需要轮换权限方。更改权限后，需要原权限方签名的待处理交易可能会失效。提交更改前，应仔细核实新的权限方。如果指定了错误或无法访问的公钥，可能会影响 Nonce 账户的后续使用。应记录权限变更，并与所有待处理的离线签名工作流协调。

每个 Nonce 值只能有一笔待处理交易

技术上，可以使用同一个存储的 Nonce 值准备多笔交易。这些相互冲突的交易中，只有一笔能成功使用该值。第一笔被接受的交易会推进 Nonce，使其他交易失效。如果工作流要求多笔延迟交易分别执行，通常应创建多个 Nonce 账户。用一个账户准备多笔待处理交易，会让这些交易相互竞争，而不是形成排队顺序。Nonce 账户不会存储未来交易列表。

持久 Nonce 与冷存储

冷存储会让重要私钥远离普通的联网系统。持久 Nonce 让冷钱包签名者无需赶在标准区块哈希过期前完成操作。在线构建系统应被视为不受信任，因为它可能准备转移资产或更改权限的交易。冷环境必须在签名前解码并显示交易的完整含义。组织应核实程序地址、账户权限、手续费设置、代币铸造地址、收款地址和交易金额。通过可移动介质传输序列化交易时，也需要实施恶意软件防护和文件完整性检查。

持久 Nonce 与财库运营

加密财库可能会使用持久 Nonce 处理需要多级审批的提现。内部申请提交后，可以先准备交易，再由不同地点的授权人员签名。最终操作人员可以在确认所有审批均已完成后提交交易。完善的财库流程应将每个 Nonce 账户与一项有记录的交易申请关联起来。组织应防止某个部门意外推进或关闭 Nonce 账户。组织还应明确规定交易消耗 Nonce 后失败时的处理流程。

持久 Nonce 与定时付款

持久 Nonce 可以保留已签名交易，直到选定的提交时间，从而支持定时付款。但它本身不会在链上强制执行时间安排。如果没有其他机制阻止提前执行，中继器可能会在预定时间之前提交交易。如果执行时间很敏感，签名者不应将已完全授权的持久 Nonce 交易交给不受信任的第三方。当链上程序在释放资金前检查网络时钟或其他经认可的条件时，可以提供更强的时间限制。所选方案还应考虑调度器不可用时会发生什么。

持久 Nonce 与智能合约交易

持久 Nonce 可用于调用 Solana 程序的交易，不仅限于简单的 SOL 转账。延迟执行智能合约会带来额外的状态风险。从签名到提交期间，兑换价格可能发生变化。借贷仓位可能变得不安全。程序预期使用的账户可能已被修改或关闭。可升级程序在交易执行时可能已运行不同的代码。在可用的情况下，应用应使用明确的最低输出、最高输入、预期账户状态和其他保护措施。用户应避免签署来自不受信任应用、权限范围不明确的持久交易。

持久 Nonce 与交易模拟

交易模拟会根据某一特定时点观察到的区块链状态，估算交易可能如何执行。模拟成功并不能保证持久 Nonce 交易之后一定成功。相关账户和程序逻辑可能在提交前发生变化。Nonce 也可能在模拟与执行之间被使用。条件允许时，应用应在计划提交时间临近时进行模拟，同时仍应依赖程序级安全限制。模拟结果不能替代对实际已签名消息的核验。

安全风险

持久 Nonce 的主要风险包括密钥泄露、未经授权推进 Nonce、指令顺序错误、账户状态过时、不安全的延迟执行，以及交易状态处理不当。被盗的 Nonce 权限方密钥可能使待处理交易失效，或授权更改账户。恶意交易构建者可能利用较长的有效期获取交易签名，并在未来不同条件下执行操作。操作人员可能因失败交易而意外消耗 Nonce。如果重试系统未能正确确认原交易的结果，就可能造成业务操作重复。安全性既取决于密码学，也取决于配套的运营流程。

监控 Nonce 账户

应用应在构建交易前读取 Nonce 账户。应用应记录账户地址、权限方、存储的 Nonce、计划交易和审批状态。提交前应再次检查 Nonce。如果 Nonce 值意外变化，说明待处理交易已不再有效。权限方意外变更可能是严重的运营或安全事件。组织应对 Nonce 推进、权限变更、余额提取和账户关闭设置警报。监控应采用适当的 Commitment 级别，并考虑最终性。

当前协议状态

当前 Solana 交易系统仍有关于持久 Nonce 的文档说明并提供支持。不过，官方持久 Nonce 页面警告称，该机制未来版本中可能会弃用。

一项Solana 改进提案讨论探讨了替代交易格式，旨在保留离线 Nonce 工作流，同时减少验证者的特殊处理。

讨论或提案并不等于网络变更已经启用。使用持久 Nonce 的开发者应关注官方规范、客户端版本、启用通知和迁移指南。长期运行的机构系统不应假设当前交易格式永远不会改变。

开发者应如何实现持久 Nonce

开发者应使用经过维护的 Solana SDK 和 System Program 接口，而不要手动编码 Nonce 账户状态。应用应查询 Nonce 账户，并验证其所有者、初始化状态、权限方和当前 Nonce。

存储的 Nonce 必须放入交易的

字段。

必须是第一条指令。

Nonce 权限方和所有其他必需签名方必须对完全相同的消息签名。系统应存储序列化交易和签名，不得对其进行修改。提交前，应用应确认账户中仍存有预期的 Nonce 和权限方。提交后，应用应检查交易状态、执行错误、Nonce 推进情况、手续费和预期账户变化。

用户如何安全使用持久 Nonce

如果不需要延迟签名，应优先使用带近期区块哈希的普通交易。应通过能够清晰标明 Nonce 账户和权限方的软件使用持久 Nonce。离线签名者应核验每条指令，而不是批准无法读取的序列化消息。如果需要取消待处理交易，应通过主动推进 Nonce 来取消。用户应了解，取消操作会消耗旧值，并使基于该值构建的所有交易失效。Nonce 权限方密钥应根据账户价值和运营用途进行备份与保护。用户应核实交易是否成功执行，而不能假设 Nonce 已推进就代表预期转账成功。

持久 Nonce 的常见错误

一个常见错误是将持久 Nonce 当作递增的钱包交易编号。

另一个错误是将计算预算指令放在

之前。

第三个错误是使用同一个 Nonce 准备多笔交易，并期待它们全部执行。第四个错误是认为持久 Nonce 会自动安排未来执行。第五个错误是忽略签名与提交之间发生的区块链状态变化。第六个错误是以为交易失败后 Nonce 仍可用于再次尝试。第七个错误是在仍有已签名交易待处理时关闭或重新授权 Nonce 账户。第八个错误是未检查原交易状态，就重新提交或重建交易。第九个错误是将 Nonce 账户所需的免租金余额写死在代码中。第十个错误是认为未来 Solana 版本永远不会改变当前的持久 Nonce 行为。

常见问题

Solana 中的持久 Nonce 是什么？

持久 Nonce 是存储在 System Program 账户中的持久哈希值，用来替代有效期很短的近期区块哈希。

普通 Solana 交易为什么会过期？

普通交易包含近期区块哈希，而网络只会在 150 Slot 的处理年龄窗口内接受该哈希。

持久 Nonce 会在 150 Slot 后过期吗？

不会。超过该窗口后，它仍可使用，直到 Nonce 账户被推进、关闭，或以其他方式发生导致交易失效的变化。

持久 Nonce 会让交易永久有效吗？

不会。存储的 Nonce 被使用，或所需账户和权限条件不再匹配时，交易就会失效。

什么是 Nonce 账户？

这是一个由 System Program 所有的账户，存储 Nonce 权限方、持久 Nonce 值和手续费相关状态。

谁控制 Nonce 账户？

指定的 Nonce 权限方负责批准推进、权限变更和提现操作。

Nonce 权限方必须支付交易手续费吗？

不必。Nonce 权限方和手续费支付方可以是不同的签名账户。

哪条指令必须放在首位？

持久 Nonce 交易必须将

指令放在第一位。

计算预算指令可以放在首位吗？

不可以。持久 Nonce 交易中，计算预算指令不得放在

之前。

持久 Nonce 交易可以离线签名吗？

可以，离线签名是该机制的主要用途之一。

持久 Nonce 会安排付款吗？

不会。另一个系统必须在预定时间提交已签名交易。

多笔交易可以使用同一个 Nonce 吗？

可以准备多笔，但只有第一笔被接受的交易能够成功使用该 Nonce。

如何让多笔延迟交易分别执行？

通常应为每笔交易使用不同的 Nonce 账户和单独存储的 Nonce 值。

Nonce 使用后会发生什么？

Nonce 账户会存储一个新值，使用旧值签名的交易则会失效。

如果后续指令失败会怎样？

普通状态更改会回滚，但 Nonce 仍会推进，交易手续费也仍会收取。

持久 Nonce 交易失败后可以重新提交吗？

如果 Nonce 已被使用，就不能重新提交；必须使用新值重新构建并签名交易。

如何取消待处理的持久 Nonce 交易？

权限方可以通过另一笔有效交易推进 Nonce，使旧的已签名交易无法使用。

更改权限方会使待处理交易失效吗？

会。账户权限方变更后，使用旧权限方签名的交易可能会失败。

Nonce 账户需要 SOL 吗？

需要。账户在保持活跃期间必须维持适用的免租金余额。

可以从 Nonce 账户提取资金吗？

可以，但部分提取后必须保留免租金余额；提取全部余额则会关闭账户。

持久 Nonce 是一种加密货币代币吗？

不是，它是存储在 Solana System Program 账户中的交易状态。

持久 Nonce 是秘密吗？

不是。Nonce 账户及其中存储的值都可以在链上公开读取。

知道 Nonce 就能盗取资金吗？

不能。交易仍需要 Nonce 权限方和所有其他必需签名方提供有效签名。

攻击者能使已签名交易失效吗？

控制 Nonce 权限方的攻击者可以推进或更改 Nonce 账户，使待处理交易失效。

模拟成功能保证之后执行成功吗？

不能。账户状态、程序、余额、价格和 Nonce 本身都可能在提交前发生变化。

持久 Nonce 比普通交易更贵吗？

持久 Nonce 需要额外账户状态和推进指令，但普通签名费和优先费仍然适用。

当前仍支持持久 Nonce 吗？

支持，但官方文档警告，当前机制未来版本中可能会弃用。

结论

持久 Nonce 可以让 Solana 交易在标准的 150 Slot 近期区块哈希窗口结束后继续有效。它通过由 System Program 所有的 Nonce 账户实现，该账户包含权限方、存储的哈希值和手续费相关状态。已签名交易消息中的普通近期区块哈希会被存储的 Nonce 替代。

交易必须将

放在首位，并包含 Nonce 权限方的签名。

交易被接受后，Nonce 会推进，旧的已签名消息也无法再次重放。如果后续指令失败，预期的状态更改会回滚，但 Nonce 仍会被消耗，手续费也仍会收取。持久 Nonce 尤其适用于气隙签名、财库审批、多方授权和延迟提交。它不会自动安排交易，也无法保护签名者免受恶意指令或不断变化的区块链状态影响。安全实现需要监控 Nonce、确保消息完全一致、清晰显示交易、可靠检查状态，并谨慎管理权限。由于当前设计未来可能在 Solana 版本中发生变化，开发者应关注官方协议指引，并在必要时为运营系统准备迁移方案。