getblockfilter怎么核对区块过滤器？

“紧凑区块过滤器”容易与“紧凑区块传输”混淆。getblockfilter读取的是BIP 157内容过滤器，目的是帮助客户端判断某个区块是否可能包含它关心的脚本；它不负责像BIP 152那样减少节点间传播完整区块时的带宽。

先画清四个对象

区块保存真实交易；basic过滤器从区块内容构建出紧凑匹配结构；filter header把当前过滤器哈希与前序头链起来；轻客户端用自己的关注项测试过滤器，命中后再请求区块或相关证明。四者层级不同，不能把filter hex当成区块摘要，也不能把header当成交易Merkle证明。

getblockfilter按必填blockhash获取某个区块的BIP 157内容过滤器，filtertype可选且默认basic。调用时必须给出blockhash，filtertype可省略且默认basic。稳定的工作流通常先从可信链视图取得目标区块哈希，再读取对应过滤器；若直接接收外部传入的任意哈希，至少要先确认它属于预期网络和当前节点可识别的链。

调用前置比命令本身更重要

节点需要具备相应过滤器索引。运维上先用getindexinfo检查索引是否存在、是否同步完成，再决定能否为业务提供服务。RPC报错时要区分索引未启用、索引仍在追赶、区块不存在和传输故障，不能统一重试到超时。

索引开启会带来额外磁盘和构建时间。新节点在区块链同步完成前，过滤器索引也可能还未追平。服务就绪检查应该同时观察链同步和索引状态；只看到进程端口可连接，不等于getblockfilter已经能稳定回答历史查询。

成功结果只有hex编码的filter和header；前者是过滤器数据，后者是过滤器头。 filter是hex编码过滤器数据，供客户端测试关注项；header是hex编码过滤器头，供客户端校验过滤器头链的一致性。两者都应该原样保存，再在展示层做缩写。只保留前后几位虽然适合界面，却无法用于重放和字节级核对。

返回项	用途	不能证明
filter	测试区块是否可能相关	命中项一定真的存在
header	串联并核对过滤器头链	区块内具体交易内容
blockhash	定位查询的区块	当前仍在活动链且已最终稳定

对账时应记录节点版本、网络、blockhash、filtertype和返回值。如果两台节点对同一活动链区块给出不同字节，先确认软件版本、索引完成度和链视图，再调查数据完整性。

为什么命中后仍要下载数据

BIP 157定义客户端以区块过滤器测试关注脚本，过滤器匹配会带来候选区块但存在假阳性，因此仍需取区块数据完成确认。紧凑过滤器允许假阳性：过滤器可能判断“有可能相关”，但取回区块后并没有客户端真正关心的输出。设计允许这种情况，是为了在空间、网络效率与隐私之间取平衡。安全实现必须把命中当成候选，不把它直接计入余额或交易历史。

没有命中也要放在正确模型里解释。客户端构造查询元素、脚本类型或派生范围错误，可能造成业务层漏检；这不是过滤器机制自动替你解决的问题。钱包恢复时应确认描述符、地址范围和网络，再决定扫描区间。

一条完整的轻客户端核验链

第一步固定检查点或可信区块头；第二步同步过滤器头并检查连续性；第三步获取目标区块的basic过滤器；第四步测试本地关注项；第五步只对命中区块拉取足够数据，验证交易与区块关系；第六步随着链头变化处理确认数和重组。

这条链中任何一步都不能由“RPC返回200”替代。HTTP成功只说明节点给了格式可解析的结果，不证明上游节点诚实，也不证明业务关注项生成正确。高价值钱包应使用多源核验、可信检查点或自己的全节点，不把公共RPC当成无条件信任根。

适合监控的四类异常

索引落后于链头：服务应降级，而不是返回旧结果冒充实时。
相同区块的filter在同版本节点间不一致：固定链视图后再升级调查。
header链断裂：停止把后续过滤器交给余额计算。
命中率突然异常：检查关注项范围、脚本类型与索引版本，避免直接归因于链上行为。

过滤器只负责缩小调查范围

可靠实现会保留区块哈希、过滤器类型、filter、header和后续区块核验结果。命中只是开始，真正的交易存在与确认仍要回到区块数据。