协议演进 / BIP/比特币改进提案 / BIP-33
BIP-33
设想让轻客户端把区块链查询交给少数专业服务节点，并以多服务交叉核对防作恶；方案最终关闭，未成为现行协议。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-33 |
|---|---|
| 标题 | Stratized Nodes |
| 作者 | Amir Taaki <[email protected]> |
| 指定日期 | 2012-05-15 |
| 层级 | Peer Services（对等服务） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/33 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki |
二、放在哪一族
BIP-33 属于轻客户端与节点分工这一族：当完整区块链越来越大时，普通用户的设备怎样在不保存、不验证全部数据的前提下，仍然查到自己的交易历史？
它的历史脉络在原文中写得很清楚：2011 年 Jan Moller 的 BCCAPI 先开了“把区块链交互委托给远程服务器”的路子；ThomasV 的 Electrum 服务器随后跟进，要求全套自由软件栈；Marek Palatinus（slush）又起草 Stratum 来接替 Electrum 服务器的角色。BIP-33 提出的 stratized nodes，是“区块链服务”（blockchain service）这一更早概念的修改版，目标是规范地接替 Stratum 当时所扮演的、为用户客户端提供区块链查询的角色。
同族后来真正落地的路线不同：BIP-37 的布隆过滤让 SPV 客户端直接向普通全节点要过滤后的数据，再往后还有 BIP-157 与 BIP-158 的客户端区块过滤。读 BIP-33，是看清“专用服务节点”这条路线曾被认真设计过、最终又未被采用。
三、它要解决什么
原文开篇判断：网络规模扩大后，角色正在专业化。早期一个用户同时是矿工、商家和终端用户；随着系统成长，这些功能被抽象成专门服务，是自然结果。
问题随之而来：区块链对终端用户越来越笨重，在便携设备和低端机器上处理它越来越不现实。已有的应对办法——轻量（只存区块头）客户端、跳过最后一个检查点之前区块的验证——在作者看来至多是拖延问题的临时 workaround，解决不了根子上的负担。
因此方案的目标被限定得很明确：把区块链验证与查询的负担，从用户客户端身上卸给专业服务，并且要以安全的方式卸——原文强调，任何附带的好处都只是次要的。
作者对当时 Stratum 的评价也写进原文：Stratum 已无人维护，容易遭受资源饿死与拒绝服务攻击，且不安全。新协议正是要替代它的这一角色。
四、规则本身
4.1 两种新节点角色
节点在握手时的 version 消息里有一个 services 位域，用来宣告自己支持哪些服务（NODE_NETWORK 即值 1，表示可被索取完整区块）。BIP-33 新增两个值：
- NODE_SERVICE（2）：区块链服务节点，支持新增的
getoutputs与getspends消息；它本身不回应getdata（除非同时标了NODE_NETWORK）；若标了NODE_NETWORK，用getdata取交易时不仅查内存池，必要时还查区块链； - NODE_STRATIZED（4）：采用本方案策略的节点；会中继已接受交易的 inventory；不支持
getblocks，因为它并不保存完整区块链。
除上述差别外，两类节点的行为与 NODE_NETWORK 节点相同。
4.2 四个新消息：按地址查历史
方案定义四个新消息（原文以 C 风格伪代码给出结构）：
getoutputs：带一个解码后的地址（支付类型加 16 字节地址哈希），问“这个地址收到过哪些输出”；outputs：回应输出点（outpoint）清单，每项是交易哈希加输出索引；getspend：带一个输出点，问“这个输出被哪笔输入花掉了”；spend：回应花费它的输入点。
典型流程是：先发 getoutputs 拿到某地址的全部输出点，逐个用 getdata 下载对应交易，并逐个发 getspend 查花费情况；收到 spend 回应后再下载花费交易。这样就能逐步、快速地拼出一个地址的完整历史，而无需本地访问区块链。
更新方面，stratized 节点照常接收服务节点的 inv 通告并用 getdata 取数据，从中检查与自己有关的新收付；同时它至少要验证区块的默克尔根，并检查交易的唯一性。
4.3 安全模型：多服务交叉核对
把查询交给别人，最大的担忧是被服务节点欺骗。方案的办法是分散信任：一个 stratized 节点通常连接 8 个区块链服务，只接受被这些服务中一个公共子集共同发来的输出、花费或 inventory 向量（原文举例为 6 个）。这样单个作恶的服务左右不了结果，风险被摊到多个服务身上。
4.4 隐私
原文承认，本方案与只存区块头的 SPV 客户端有同样的隐私问题，并给出同样的缓解思路：像 SPV 那样发出足够多的假请求来混淆真实查询，使隐私保持在足够水平。
4.5 取舍与兼容
NODE_SERVICE 默认不回应 getdata，是为了防饿死攻击：单个可信服务（背后可以挂多个后端）可以服务大量节点，而把成本外部化到比特币网络。NODE_STRATIZED 则尽力维持对网络的贡献（如中继），但因没有完整区块链而无法支持 getblocks。
本方案是对现有网络的附加，原文称其完全向后兼容。
五、谁必须动
普通持币人：若使用这类轻客户端，不必保存完整区块链，改为向多个服务节点查询并交叉核对——设备负担小了，信任假设也随之变了。
钱包与轻客户端开发者：要实现四个新消息、地址历史的拼接流程，以及“多服务取公共子集”的核对逻辑和假请求混淆。
服务节点运营方：要保存完整区块链与索引，提供 getoutputs / getspends 查询，并按规则处理 getdata，是整套方案里负担最重、也最中心化的角色。
全节点与共识层：规则本身不变；普通全节点不参与这套分工也能照常运行。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭）。BIP-33 没有成为现行协议的一部分：今天的钱包并不通过 NODE_STRATIZED 服务位和这四个消息查历史，轻客户端实际走通的是布隆过滤与后来的紧凑区块过滤等其他路线。本页保留它，是因为它完整记录了早期社区怎样思考“节点分工与信任分散”——设计本身有想法，不等于被网络采纳。
常见误读：
“连上专业的区块链服务节点查账，和自己跑全节点一样安全。”
不对。原文自己就把安全问题列为核心关切：stratized 节点是“任由区块链服务摆布”（at the mercy of blockchain services）的一方，方案只能靠同时连多个服务、取公共子集来分散风险。这与自己保存并验证整条链有本质区别——前者是把验证外包后做交叉核对，后者是根本不外包。
七、延伸
- 阅读版：https://bips.dev/33
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki
- 相关：BIP-37 连接布隆过滤、BIP-157 客户端区块过滤、BIP-158 紧凑区块过滤器
- 仓库总目录：https://github.com/bitcoin/bips