Compact Block Filters

安娜隔了一段时间重新打开手机钱包。应用需要查明，上次联网后是否有人向她付款，以及她的资金是否已被花费。钱包不下载全部交易，而是下载小型过滤器，与自己监控的输出条件比较。输出是交易中规定金额及其后续花费条件的部分。若出现匹配，应用就请求整个区块，再寻找实际交易。不能仅凭过滤器匹配增加余额。过滤器既不是账户对账单，也不是所有权证明。搜索前，客户端会同步区块头，即标识区块的简要数据，以及相互连接的过滤器头。 [1]

在较早的 BIP 37 方案中，客户端根据希望监控的数据构建过滤器，再发给对等节点。这里方向相反：服务器提供区块过滤器，安娜在本地搜索。对于相同区块和过滤器类型，客户端拿到的内容相同，因此不必直接向每台服务器透露所查脚本。但这不等于匿名：对方仍可能看到 IP 地址、连接时间，以及钱包随后请求了哪些完整区块。把下载分散到不同节点，可以减少单个节点掌握的信息，却不能消除所有关联分析。 [1]

Compact Block Filters 用于选择值得检查的区块。BIP 152 中的 Compact Blocks 解决另一个问题：传输区块时，用交易的短标识符节省数据，因为接收方往往已经知道这些交易。接收方从自己的 Mempool，也就是本地未确认交易集合中取出交易，再请求缺失部分。这两种工具本身都不负责检查 Bitcoin 的全部规则。Full Node，即全节点，会独立按网络规则验证区块和交易。轻量钱包若只检查区块头和自身交易是否被包含，执行的是范围更窄的检查。节省数据与完整验证是不同属性。 [1] [5]

BIP 158 规定了格式。basic 过滤器包含新输出的 scriptPubKey，即规定花费条件的脚本，但排除以 OP_RETURN 开头的输出；还包含该区块花费的旧输出脚本。对于输入，例外是 coinbase：它是区块中分配矿工报酬的首笔交易，不花费普通的旧输出。它的新输出仍按与其他新输出相同的规则纳入过滤器。空项目会被省略。钱包必须把地址转换成正确脚本，仅搜索印出来的地址文字不够。过滤器不是通用搜索引擎，不能任意搜索交易标识符 txid、签名等 witness 数据或各种备注。 [2] [3]

下载区块后，安娜可能发现里面没有自己的内容。这种误匹配是缩小过滤器的正常代价，本身不证明软件出错。技术上，项目先被转换成数字指纹并排序，再用 Golomb-Rice 编码紧凑地保存相邻差值。basic 使用 P=19 和 M=784931。查询一个不存在的项目，匹配概率约为 1/M；监控更多项目，就有更多出现匹配的机会。这不是整个钱包固定的错误率。正确构建的过滤器不会遗漏已包含的项目。但要相信否定结果，过滤器本身、所覆盖的数据类型和查询内容都必须正确。 [2]

BIP 157 规定过滤器的传输及其头部链接。每个过滤器头把当前过滤器的 hash，即密码学指纹，与上一个过滤器头连接起来。修改过滤器会破坏预期链接。但这条链不属于 Bitcoin 区块头，挖矿并不直接承诺它的内容。不诚实的节点可以准备虚假过滤器，同时算出数学上正确的连续指纹。这不会改变 Bitcoin，却可能向被隔离的客户端隐瞒信息。因此，检查链接计算是否正确，还必须配合检查底层数据是否真实。 [1]

BIP 157 依靠比较多个节点，并要求其中至少有一个诚实来源。出现分歧时，客户端可以定位第一个不同之处，再根据原始数据验证过滤器。构建 basic 可能不只需要新块：还需要其交易所花费的旧输出脚本。重组需要专门处理，即网络切换到另一条有效区块分支，后者有更多累计工作。钱包必须把过滤器接到新分支上，并更新历史和余额。同一高度，也就是链中的同一位置，不一定指同一个区块。 [1] [3]

钱包既需要可获取的过滤器，也需要拿到所选完整区块的途径。节点可能在生成过滤器后删除旧块，此时必须由其他来源提供。在 Bitcoin Core 中，启用相应索引后，getblockfilter 会返回指定区块的过滤器和过滤器头。这个命令可用，不代表节点对外提供 P2P 服务，也不代表它保存着全部历史。现有区块的过滤器还不会通报 Mempool 中尚未确认的交易。应用若要显示待确认付款，需要另一个机制。这些运行细节决定轻量钱包是否真正好用。 [1] [4]