Chainstack 排查 Solana 交易过期：用 block height 比较有效期
链小知 · 进阶 · 核验 · 依官方文档整理
复核 getLatestBlockhash 和 getBlockHeight 的既有记录，检查网络、commitment 和比较对象，识别把 slot 当高度的误判。
开始前准备
- 准备同一 Solana 网络的节点标识、脱敏请求/响应、记录时间和已使用的 blockhash；URL token 与 Basic Auth 凭据须遮盖。
- 至少有 getLatestBlockhash 响应和后续 getBlockHeight 响应；缺少其中之一时只能标记证据不足。
1. 确认是 Solana 节点入口
在已有配置中核对节点网络与记录来源。Chainstack 平台管理 API 用 Bearer key，节点入口用自己的 URL token 或 Basic Auth，不能把 api.chainstack.com 的管理凭据放入 Solana RPC。把节点标识与网络保存，凭据只保留已脱敏的位置说明。
检查结果：两份记录来自同一网络，入口是节点 RPC，凭据已遮盖。
2. 读取实际使用的 blockhash 和有效高度
在 getLatestBlockhash 的 result 中分别取 context.slot、value.blockhash、value.lastValidBlockHeight。先确认 value.blockhash 与待排查交易当时使用的哈希一致，再保存有效高度；刚取得的另一个哈希不能用来解释旧交易。当前 Solana 规范支持可选配置 commitment/minContextSlot，Chainstack 页内旧 schema 不能代替真实字段。
检查结果：旧交易哈希与对应响应相匹配，slot 和 lastValidBlockHeight 分列。
3. 对齐 commitment 并读取区块高度
查已有 getBlockHeight 请求的配置，例如 params:[{commitment:"confirmed"}]，与取得哈希的 commitment 对照。其 result 是整数 block height；context.slot 是 slot，二者不能互换。记录采样时间，来自另一网络、不同 commitment 或明显过旧的高度先排除。
检查结果：用于比较的是同环境、同 commitment 的整数高度，且时间顺序明确。
4. 只做有效期判断
将后续 block height 与该旧哈希的 lastValidBlockHeight 比较：高度超过有效高度才可据这组记录判断哈希有效期已过；高度未超过时，仍需另查交易执行与确认。不要拿 slot 相减，也不要从一次余额变化判断该交易是否成功。记录缺失、请求 error 或哈希不匹配时，结论写为无法判断。
检查结果：结论附两个高度与原哈希；有效期判断和交易成功状态分别记录。
5. 核对排查请求的服务用量
按节点类型核对这些读取的 RU，不把 API 用量当交易 Gas。Global Nodes 按方法和历史范围归类，Trader Archive 可能所有请求都按 Archive 计；extra usage 开启后超额度可能继续收费。整理已有记录即可定位误判，不以不断重发旧交易作为排查方法。
检查结果：报告包含节点模式、已读记录、过期判断和待查交易状态，没有把排查次数当链上执行次数。
怎样确认完成
- 输出匹配旧哈希的 lastValidBlockHeight、后续 block height、网络、commitment 与可判断或证据不足的结论。
- 教程通过官方文档交叉核验；尚未进行节点调用或交易实测。
常见错误与边界
- 浏览器的 block 链接可能实际使用 slot，不能从链接数字推定 block height。
- 新取得的 blockhash 有效不代表旧交易哈希仍有效。
- 文档中的 150 blocks 示例不是可直接换算的固定秒数。