常见用例
- 交易重试: 在重试失败的交易之前,检查其原始 blockhash 是否仍然有效。如果无效,则必须获取新的 blockhash。
- 延迟交易签名: 如果交易已准备好但稍后才签名和提交,请在提交前验证 blockhash 的有效性。
- 乐观交易处理: 确定如果立即发送交易,blockhash 是否可能被网络接受。
请求参数
- (string,必需): 要检查的 blockhash,作为 base-58 编码的字符串。
- (object,可选): 一个可选的配置对象,可以包括:
- (string,可选): 指定查询的承诺级别(例如,)。如果省略,则使用节点的默认承诺。
- (u64,可选): 请求可以评估的最低插槽。这确保了 RPC 节点不会返回来自比该插槽更早的状态。
响应结构
JSON-RPC 响应中的字段是包含以下内容的对象:- (object): 包含:
- (u64): RPC 节点评估 blockhash 有效性的插槽。
- (boolean): 如果 blockhash 仍然有效,则为 true,否则为 false。
代码示例
开发者提示
- Blockhash过期: Blockhash仅在有限时间内有效(大约150个槽位,或约1-2分钟)。如果不确定或已经过去了相当长的时间,请始终获取新的blockhash。
minContextSlot用法: 使用minContextSlot来防止查询过期的RPC节点,该节点可能会对实际上对集群其余部分来说太旧的blockhash给出过时的”有效”响应。- 旧节点的替代方案: 对于运行低于Solana 1.9版本的节点,使用
getFeeCalculatorForBlockhash("<YOUR_BLOCKHASH>")。如果此方法成功返回,blockhash有效。如果出现错误(通常是因为blockhash未找到或太旧),则blockhash无效。 - 网络确认: 即使
isBlockhashValid返回true,只有在提交后达到网络所需的承诺级别后,事务才最终确定。
isBlockhashValid RPC方法所需的详细信息。
相关方法
getLatestBlockhash
获取新交易的最新blockhash