搜索首先要明确数据对象
理解区块链搜索方法涉及哪些技术概念，可以从三个问题入手：要查什么、用什么定位、怎样判断结果。查询一笔交易、读取某个时点的账户状态、验证交易是否进入区块，分别需要不同的数据与方法。以太坊和比特币的数据结构存在差异，不能直接套用同一查询模型。
哈希与区块高度承担不同作用
比特币开发文档说明，区块通过前一区块头的哈希相连；分叉时，同一高度可能出现多个区块，因此高度不能作为全局唯一标识。交易标识则用于定位交易记录。
这意味着，检索时应区分位置与身份：高度描述区块在链上的位置，哈希用于标识具体对象。如果需要复核一次查询，仅记录高度可能不足，还应明确所属网络与具体区块。
节点接口与状态查询
以太坊JSON-RPC文档说明，应用通过节点接口读取链上信息。查询余额、代码或合约状态时，区块参数决定查询时点；数值与字节数据虽然都使用十六进制表示，但编码规则不同。
因此，状态查询必须同时明确对象和时点。询问某个地址的余额，如果没有指定区块范围或状态标签，结果的含义就不够完整。接口返回的数据也需要按字段类型解释，不能把所有以0x开头的内容都当成普通整数。
UTXO与默克尔树解决什么问题
比特币以交易输出是否已被花费来组织UTXO信息。默克尔树则把交易哈希逐层汇总到区块头中的根值，使客户端能够利用中间哈希验证交易的包含关系。
两者对应不同检索目标：追踪交易之间的关联，需要理解输入引用输出的结构；核验某笔交易是否被指定区块收录，需要包含证明。包含证明本身不能回答该交易输出后来是否被花费，也不能替代全部共识规则的验证。
适用条件与常见问题
为什么同一次状态查询可能得到不同结果？以太坊的latest、pending等标签对应不同状态，节点同步情况也会影响其可提供的信息。需要可复核的结果时，应明确查询时点，并检查节点状态。
为什么查到记录还需要验证？接口检索解决数据获取问题，哈希关联与证明解决特定范围内的核验问题。解释搜索结果时，应把交易记录、账户状态和区块包含关系分开，避免从单个返回值推导出它并未证明的结论。