比特币网络刚起步时，一个用户往往身兼三职：自己跑全节点、自己收付款、甚至自己挖矿。到 2012 年，这个画面已经变了——区块文件在膨胀，手机和低配机器越来越难扛住同步与验证的负担。BIP-33《分层节点》就是在这个转折点上写的：作者 Amir Taaki 提议把”谁替谁保管区块链”这件事写进节点握手的公告位里，让轻量客户端能安全地把链上查询外包出去。这份提案 2012 年 5 月立项，最终状态是 Closed，从未部署，但它背后那条”把区块链交互委托给远端”的路线，恰恰是今天轻钱包生态的雏形。
要理解它为什么长这样，得先看它站在谁的肩膀上。提案的 History 一节交代了谱系：2011 年 Jan Moller 做了 BCCAPI，让客户端把区块链的存储和查询交给一台远端服务器；ThomasV 的 Electrum 服务器因为 BCCAPI 后端不开源而另起炉灶；Marek Palatinus（slush）又起草了 Stratum 标准来替换 Electrum 那套临时方案。BIP-33 对 Stratum 的评价相当直白：无人维护、容易被资源饿死、扛不住拒绝服务攻击。所以它把自己定位成”接替 Stratum 作为轻客户端区块链服务”的角色——注意，只是接替这条路线里”给用户客户端供链”的那一段，不涉及矿工程。
它的机制核心是复用握手协议里已有的东西。比特币节点建立连接时会互发 version 消息，里面有一个 64 位的 services 位图，NODE_NETWORK（值 1）表示”可以向我索要完整区块”。BIP-33 提议加两个值：NODE_SERVICE（值 2）和 NODE_STRATIZED（值 4）。前者代表一台支持额外查询消息的区块链服务节点，它自己不应答 getdata（除非同时挂了 NODE_NETWORK）；后者代表采用”分层策略”的节点，会像普通节点一样转发已接受交易的 inv 公告，但不支持 getblocks——因为分层节点根本不带整条链。两个位一挂，客户端在握手阶段就能看出对面能干什么、不能干什么，不用先连上再试探。
查询侧定义了四条新消息：getoutputs、outputs、getspend、spend。前一对按地址询问”这个地址有哪些未花费的输出点”，回复里带一组 (哈希, 序号) 对；后一对按某个输出点询问”它被哪笔交易的哪个输入花掉了”。四条消息拼起来，一个不带全链的客户端就能沿着一串 outpoint 反向重建某个地址的收支历史，而服务节点也不必把区块整块推过去。这套设计与今天 Electrum 服务器应答订阅查询的思路神似，区别在于 BIP-33 想把它做成所有节点都可能挂的通用服务位，而不是某个钱包软件的私有协议。
为什么它没走下去？一个直接原因是分工路径的取舍：与其让普通节点兼职做查询服务，社区后来更愿意让专用索引服务器（Electrum 服务器、Esplora 这类）去承担这个角色，P2P 协议层保持精简。另一个原因是信任模型没有变：就算节点挂了服务位，客户端仍然无法验证答案的真伪——它信任的是那台服务器，而不是密码学证明。后来的历史选择了 SPV 默克尔证明和 BIP-157/158 的压缩区块过滤这条”可验证”的路线，让轻客户端至少能自己核对一部分答案。
常见误区有三个。其一，把 BIP-33 和挖矿用的 Stratum 协议混为一谈：Stratum 后来在挖矿代理领域演化出 V1/V2 的生命，而 BIP-33 想淘汰的是 Stratum 里”给用户供链”的那一半，两者对象不同。其二，把 NODE_SERVICE 与后来 BIP-111 等提案里的服务位当成同一批分配：那些位各有归属，2 和 4 这两个值并没有作为标准服务位沿用下来。其三，以为分层节点是”更轻的全节点”：它本质上是一种角色声明——我替你存链、你信任我——而不是数据裁剪方案。
快速问答。问：今天还有哪些比特币软件在概念上接近分层节点？答：Electrum 与其服务器、各类 REST/JSON-RPC 区块链索引服务都是同一家族，只是它们走私有协议，不靠 version 消息里的服务位互相发现。问：普通用户需要关心这个提案吗？答：不需要；它已关闭，主网节点没有实现这些位。问：为什么轻客户端不能完全自证？答：因为要验证任意查询的答案，客户端要么下载并验证相关区块，要么需要密码学 accumulator 类结构，前者接近全节点成本，后者在当年还不成熟。
风险提示：本文是协议史与机制科普，不构成投资建议；使用任何依赖远端服务器的轻钱包时，请理解服务器对查询结果的信任边界。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。