isBlockhashValid
RPC 方法用于检查先前获取的 blockhash 是否仍被网络视为有效。Blockhash 的有效期有限(大约 2 分钟或 150 个区块),之后引用它们的交易将被拒绝。
此方法对于在提交交易前保留 blockhash 一段时间的应用程序至关重要,以确保交易不会因 blockhash 过期而失败。
版本说明: 此方法在 solana-core
v1.9 及更新版本中可用。对于运行 solana-core
v1.8 或更早版本的节点,您应使用 getFeeCalculatorForBlockhash
,它除了提供费用信息外,还隐含地指示 blockhash 的有效性(如果 blockhash 过旧,将会出错)。
常见用例
- 交易重试: 在重试失败的交易之前,检查其原始 blockhash 是否仍然有效。如果无效,则必须获取新的 blockhash。
- 延迟交易签名: 如果交易已准备好但稍后才签名和提交,请在提交前验证 blockhash 的有效性。
- 乐观交易处理: 确定如果立即发送交易,blockhash 是否可能被网络接受。
请求参数
blockhash
(字符串,必需):要检查的 blockhash,作为 base-58 编码的字符串。options
(对象,可选):一个可选的配置对象,可以包括:commitment
(字符串,可选):指定查询的承诺级别(例如,"finalized"
,"confirmed"
,"processed"
)。如果省略,则使用节点的默认承诺。minContextSlot
(u64,可选):请求可以评估的最小槽位。这确保 RPC 节点不会响应来自比minContextSlot
更旧的槽位的状态。
响应结构
JSON-RPC 响应中的result
字段是一个包含以下内容的 RpcResponse
对象:
context
(对象):一个包含以下内容的对象:slot
(u64):RPC 节点评估区块哈希有效性的插槽。
value
(布尔值):如果区块哈希仍然有效,则为true
,否则为false
。
代码示例
开发者提示
- 区块哈希会过期: 区块哈希仅在有限时间内有效(大约 150 个插槽,或大约 1-2 分钟)。如果不确定或经过了较长时间,请始终获取新的区块哈希。
minContextSlot
用法: 使用minContextSlot
以防止查询可能提供过时“有效”响应的陈旧 RPC 节点,而该区块哈希实际上对于集群的其余部分来说太旧了。- 旧节点的替代方案: 对于运行 Solana 1.9 之前版本的节点,使用
getFeeCalculatorForBlockhash("<YOUR_BLOCKHASH>")
。如果此方法成功返回,则区块哈希有效。如果出错(通常是因为找不到区块哈希或太旧),则区块哈希无效。 - 网络确认: 即使
isBlockhashValid
返回true
,交易只有在提交后达到网络上的所需承诺级别时才会最终确定。
isBlockhashValid
RPC 方法的必要细节。