一条带剪枝的链最容易被忽略的裂缝是：账还在那儿，但你已经无法证明它曾经在那儿。Kaspa 的 KIP-6 想补的就是这道缝，提案给的机制叫 PoChM，读作像拉丁词 pacem 的音，全称 Proof of Chain Membership，链成员证明。本文按提案原文拆它的动机、构件与边界，并说明它当前处于草案状态、不代表已上主网。
剪枝之后，「曾经被打包」怎么证明
提案的动机段落写得很直白：剪枝机制使得一笔交易被剪掉之后，无法再证明它曾被纳入账本。今天能用的替代办法是公开运行的归档节点（以区块浏览器的形态存在），但提案认为这条路不可持续，一方面依赖中心化服务方，另一方面数据库体积会随时间和使用量迅速膨胀。
它想要的是一份可密码学验证的证明：只能在交易被剪枝之前生成（或者借助归档节点生成），但可以在剪枝之后被无限期地验证。提案把这类证明分成两种：一种叫发表证明（PoP），证明某笔交易在某个时间出现在链上；另一种叫交易收据（txR），在此基础上进一步证明这笔被发表的交易被接受了，也就是说不存在另一笔与之冲突、并最终被接受的交易。这两类合称包含证明。
一个有意思的观察是提案自己点出的：收据的语义严格强于发表证明，但在 Kaspa 里反而更容易实现。原因是被接受的交易享有特殊待遇——每个选中链区块都包含一棵默克尔树的根，树里装的是该区块所接受的全部交易（提案称这个根为 ATMR）。于是「某笔交易被接受」等价于「它出现在某个选中链区块的这棵树里」。要提供收据，只要给出这笔交易被区块 B 接受的默克尔证明，再附上 B 是选中链区块的证明；要提供发表证明，则需要证明 B 是选中链区块、给出一条从 B 到某个 C 的区块头链、再给出 C 接受了这笔交易的默克尔证明。两类证明的共同难点因此收敛成一件事：证明 B 是一个选中链区块的区块头，也就是 PoChM。
从二十兆到几千字节
提案给出的现状是：在现有共识规则下，包含证明在技术上是可以构造的，但最坏情形下会长到二十兆以上，而且生成和验证都得手动做，节点里并没有实现这套功能。KIP-6 的提议是对区块验证规则做一个很小的改动，把包含证明的规模压到几千字节的量级，代价是网络在存储成本与区块验证复杂度上付出轻微开销。提案还顺手做了个参数敏感性说明：这些尺寸数字是按当前 1BPS 共识下的各参数算的，改参数要重算；但方向是明确的——提高出块率会让现有可行的证明变得更大，因为那种证明大致相当于两个相邻剪枝区块之间整份账本的体积，而提案给出的证明大小只随这段区间里的链区块数量按对数增长。
这套思路的源头是 FlyClient 一系工作：用概率采样与默克尔山（MMR）承诺，让轻客户端只下载对数级数量的区块头、在两次运行之间只保存一个区块头。值得注意的是，Kaspa 社区对 DAG 场景另有一条研究线：在研究仓库的一条讨论里，作者指出把 FlyClient 直接套到 GHOSTDAG 上有问题——蓝块的蓝色过去未必被包含在最后一个蓝块的蓝色过去里，于是「下面的 MMR 是上面的子树」这一 FlyClient 依赖的性质不成立，需要改用离它最近的链区块上的 MMR 来校验。这与 KIP-6 走的是不同路径，读的时候不要混。
边界在哪
最要紧的一条边界写在提案头部：KIP-6 标注为草案，层级是共识（硬分叉）与区块验证。它是一份提案，不是已生效的规则；能否上、何时上、参数怎么定，都要看官方 KIP 流程与实现进展。第二条边界与剪枝本身有关：PoChM 属于「区块头层」的证明，历史交易数据仍以剪枝点为界，证明要在剪枝前生成或依赖归档来源。第三条边界与信任模型有关：Kaspa 的包含性判断建立在 DAG 与选中链规则之上，把区块头层证明读成「这笔转账永远不会被回滚」是超出提案范围的。对需要在链下长期保存「我某时转过账」证据的人，这个提案改变的是取证成本，不是取证方式。本文按提案原文描述机制，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。