从getwork到Stratum：挖矿协议把建块权让给了谁

第一代：把答案连同题目一起下发

最早的挖矿协作方式叫getwork：节点或池子直接构造好一个区块头，矿机只管往里试随机数。这个设计在CPU和GPU早期够用了，但它有一个结构性问题——矿机对整个区块里装了什么交易一无所知，也无权置喙。建块权完全握在节点运营者或池主手里。理论上，一个被攻破或心怀不轨的池子可以指挥汇聚来的巨量算力去打包任意内容。再加上每个头只有4字节随机数可转、靠HTTP长轮询催新任务、用HTTP头打补丁式地塞扩展，这套协议在ASIC出现的前夜已经千疮百孔。比特币核心后来移除了getwork接口，历史版本中它仅存活到0.9.5及以下。

第二代：BIP22与BIP23把建块权交还矿机

2012年年中，社区在forrestv为P2Pool开发的getmemorypool基础上发展出getblocktemplate，并以BIP22与BIP23两份提案的形式定型，比特币核心0.7起提供该RPC。它把”题目”变成”素材”：矿机拿到上一块哈希、难度目标、候选交易全集和建块许可，自己挑选交易、自己拼默克尔树、自己决定打包顺序，算力和建块决策都回到了矿机一侧。池子仍然可以给出建议交易清单和参与规则，但不能再把矿工关进黑箱。这是比特币在算力组织方式上一次重要的去中心化修正。

第三代：没有BIP的Stratum赢了现实

同年年底，Slush矿池侧推出了Stratum：一条长连接TCP套接字，JSON-RPC格式的消息，池子按需主动推送任务；协议只下发coinbase交易和默克尔分支，把单次传输压到大约一千字节量级，天然适配矿机与池子这对固定主从关系。由于从未写成正式BIP，它此后全凭各厂商实现和讨论演化，也才有了后来有正式规范的Stratum V2改版。Stratum的代价是明确的：用它接池的矿机看不到、也改不了区块里的交易内容，建块权事实上回到了池子手里——这正是当年getblocktemplate想解决的问题。两个协议因此长期并存：自建节点与去中心化矿工用getblocktemplate，绝大多数商品矿机用Stratum连池。

回看这场竞争

这段历史值得记住的不是谁赢了，而是取舍结构：流量效率、工程简单与去中心化程度三者难以兼得。矿机固件、池子软件与全节点三者构成一条权力链，协议每往”省流量、好实现”偏一寸，交易选择权就往池主那边滑一寸。判断挖矿是否健康时，一个可操作的切入点就是看清楚：某个时期的主流协议，允许多大比例的算力在不盲从池主的情况下参与建块。

一个常被混用的词：矿机接口不等于网络协议

读矿机说明书时常遇到”支持GBT”或”支持Stratum V2”的字样，这里必须分清三层东西：最底层是全节点的RPC，比特币核心对外提供getblocktemplate；中间层是池子协议，Stratum本质上是一个把getblocktemplate的素材需求压缩成默克尔分支的翻译层——多数池子内部仍在调用节点的这个RPC来取模板，再拆成任务发给矿机；最上层才是矿机固件里那些具体的连接串与参数格式。所以”用Stratum接池”和”节点用getblocktemplate”并不矛盾，它们处在链条的不同环节。理解了这条链，就能理解为什么社区始终惦记着让矿机直连节点：只要建块素材来自矿机自己的节点，池主就只剩撮合收益的职能，去中心化叙事里那句”一CPU一票”的理想才不至于被协议现实稀释。而每次协议史的回摆——无论当年的getwork退场，还是后来围绕Stratum V2交易选择权的改造——本质都是在重新分配这条链上”谁在看、谁能选”的权力刻度。