托管型比特币产品与其他所有UTXO托管商一样，都面临着相同的数据问题。该产品需要检测数千个客户地址的入金和出金，将每个事件归因于正确的客户账户，并在不运行bitcoind和索引器集群的情况下与区块链保持同步。本文详细介绍了Bitquery上生产环境比特币托管商使用的存款对账架构。内容涵盖比特币输入输出查询结构、驱动walker的链顶心跳、地址语料库批处理模式、用于区分P2PKH、SegWit和P2SH钱包的脚本类型过滤器、地址簿对账步骤、用于资金来源合规性的Coinpath筛选、用于安全存款确认的最终性缓冲区，以及同一框架在莱特币和狗狗币上的可移植性。本文是Cardano存款指南的比特币版本。相同的三组件架构，不同的区块链，不同的UTXO模型细节。## 三组件架构 每个生产环境的比特币存款检测器都可简化为三个组件。第一个组件是链尖心跳。它按固定时间表触发，并返回当前比特币区块高度。这会告知管道的其余部分自上次扫描以来区块链的推进距离。第二个组件是地址语料库遍历器。它使用高度过滤器和一批客户地址调用比特币输入和输出查询，然后分页遍历结果。每次迭代都会将遍历范围扩展固定大小的块，直到光标追上链尖。第三个组件是协调器。它将遍历器的输出与托管机构的内部地址簿进行匹配，将每笔交易归类到相应的客户账户，应用确认缓冲区，并将存款或取款事件写入账本。这三个组件独立运行。心跳决定何时有新任务，遍历器执行任务，协调器将任务转化为业务状态。其中一个组件的故障不会影响其他组件。## 链尖心跳 心跳是一个返回当前区块高度的查询。这是管道中最便宜的查询。如果心跳触发频率高于每秒一次，则需要在本地缓存响应。比特币大约每十分钟生成一个区块，因此更高的触发频率并不会带来数据新鲜度。心跳机制有两个作用。它告诉地址语料库遍历器要获取的下一个区块的上限。它还指示链的活跃状态，因此反复失败的心跳是上游出现问题的最早指标。## 地址语料库遍历器 遍历器是主力查询。它获取在限定的区块范围内，涉及一批客户地址的所有输入和输出。inputAddress 和 outputAddress 过滤器接受一批客户地址，因此一次调用可以覆盖多个用户。较小的批次意味着更多的请求，而较大的批次在繁忙的区块范围或高活跃度的钱包上可能会超时。高度过滤器将工作限制在特定的区块范围内，这使得调用具有确定性和幂等性。每次重新运行相同的地址和高度范围都会返回相同的结果。协调器可以安全地重试一个区块。区块高度排序保证了遍历器按链顺序看到事件。存款和消耗它们的支出按它们在链上出现的顺序到达，这简化了协调器的去重逻辑。 ## P2PKH、SegWit 和 P2SH 比特币地址的脚本类型过滤 比特币地址有三种常见格式，每种格式对应一种不同的输出脚本类型。托管人的地址簿通常包含所有这三种格式，因为旧地址仍在流通，一些入站流量来自较旧的交易所，而现代钱包默认使用 SegWit。outputScriptType 过滤器将 walker 限制为 P2PKH 输出。对于 SegWit 原生地址，P2WPKH 使用 witness_v0_keyhash，Taproot 使用 witness_v1_taproot。完全移除过滤器会返回匹配的输出，而不管脚本类型如何，这在地址库是严格的白名单时有效。对于混合地址库，需要针对每种脚本类型运行单独的 walker 查询，并在 reconciler 中合并结果。对于 P2SH 钱包，请使用 scripthash。管理所有三种脚本类型的托管人会针对每个数据块运行三个 walker 查询，每种类型一个，并将结果合并后写入 reconciler。总工作量与运行一次未经过滤的查询类似，其优势在于可以单独监控每种脚本类型的数据流。## 区块大小、稳定状态和追赶机制 区块范围的区块大小是影响吞吐量的主要因素。比特币的区块间隔平均为十分钟，因此一个包含 100 个区块的区块大约可以覆盖 17 小时的链上历史，而一个包含 1000 个区块的区块大约可以覆盖一周的历史。合适的区块大小取决于地址库的活跃程度以及超时限制的严格程度。稳定状态以最高速度运行。行进器会监测心跳，当有新区块到达时，它会从上次行进的高度到链顶获取该区块。大多数情况下，该区块很小，不到一秒即可完成。当行进器落后链顶超过一个区块时，就会启动追赶模式。这种情况通常发生在部署之后、服务重启导致游标丢失之后，或长时间停机之后。## 地址簿核对 行进器返回链级数据。每个输出包含接收方地址、交易哈希、输出索引和值。链本身并不了解哪个客户拥有该地址。这种映射关系存在于托管机构自身的系统中。核对器是连接这两个系统的组件：它获取行进器找到的每个输出，并在托管机构的内部地址簿中查找接收方地址，从而将存款归属于某个客户。核对器维护两个表。第一个是地址簿，将每个客户映射到为其生成的存款地址。第二个是账本，它是托管机构存款和取款的真实数据源。对于 Walker 返回的每个输出，对账器都会在地址簿中查找接收方地址，将值归属给客户，并根据交易哈希和输出索引对，将存款事件写入账本。地址簿查找是关键路径；应将其保存在内存或低延迟的键值存储中。## 使用 Coinpath 进行资金来源筛选 受监管的托管机构在归属之后通常还有第二项任务。在存款清算到客户可用余额之前，后台需要了解资金来源。发送方的地址是否属于受制裁实体？资金在最后几跳中是否经过了已知的混币器？比特币 Coinpath API 可以回答资金来源问题。最简单的筛选查询是深度为 1 的入站追踪。将发送方地址通过内部制裁列表和已知混币器注册表进行查询。如果匹配成功，则会暂停存款入账，并将该案例路由到合规队列。如果未匹配成功，则对账器可以继续处理确认缓冲区。为了更深入地了解资金来源，可以增加追踪深度，追溯 N 跳。## 六确认缓冲 比特币交易并非在出现在区块中的那一刻就最终确定。区块重组可能会使最近挖出的区块失效，并回滚其中任何已记入的存款。标准的缓解措施是将存款确认延迟固定数量的区块，比特币通常为六个区块。Walker 仍然可以在每次提示时获取每个区块并将其提供给协调器。协调器会将事件保持在待处理状态，直到它们清空缓冲区，然后将其提升为已确认状态。## Bitquery 与自托管 bitcoind 加索引器 另一种自然的选择是运行 bitcoind 并连接到索引器，例如 Electrs、BTC RPC Explorer 或 Esplora，然后通过 RPC 或 HTTP 查询该索引器。对于某些团队来说，这是一个合理的选择，但对于大多数托管机构来说，这是一个错误的选择。Bitquery 提供更快的首次存款速度、无需磁盘空间，以及内置的地址批量过滤和脚本类型解码功能。## 多 UTXO 可移植性：莱特币和狗狗币上的相同循环 上述整个协调模式无需架构更改即可移植到其他 UTXO 链。将网络参数替换为莱特币或狗狗币，并替换语料库中的地址格式，即可在新链上运行相同的心跳检测、Walker 和 Reconciler 组件。支持 BTC、LTC、DOGE 和 BCH 的托管机构会针对同一底层 Bitquery API 运行四个循环实例，每个链一个实例。## 整合 完整的存款检测循环很短。托管机构的存款和取款数据现在由比特币链状态驱动，无需运行任何节点集群。这与 Bitquery 上生产环境比特币托管机构使用的架构相同。它与 Cardano 存款指南和 Avalanche 余额轮询指南相结合，可在 UTXO 和 EVM 链上提供完整的托管数据层。## 总结 大规模检测存款和取款的托管比特币产品有三种实际选择：构建和运行比特币节点集群和自定义索引器；从托管 RPC 提供商获取数据流，并根据每次调用重建 UTXO 移动。或者运行一个提示心跳机制，再加上一个地址语料库遍历器来检测 Bitquery，然后让协调器处理归属问题。[Bitquery]