Bitcoin(BTC)核心软件32.1版本将并行验证上限提升至16个工作线程

共享队列:为繁忙网络瘦身

Bitcoin (BTC)全节点软件Bitcoin Core的开发团队在10月27日星期二发布的32.1版本中,把一项队列改动放在了核心位置。新版本重写了节点向对等节点传递交易的方式:过去每一个连接都各自维护一条出站队列,如今节点改用一条共享队列统一调度。官方发行说明指出,在交易量高企的时段,这一改动能压缩内存与CPU占用。共享只发生在节点内部,整个比特币网络并不运行在一条公共队列上。全节点会独立验证每一笔交易和每一个区块,旧设计下每条对等连接都携带着自己的待广播交易缓冲区,中继占用的内存随连接数量线性增长,共享设计则把这笔成本在节点层面一次性合并。中继限额带有明确数字:交易中继的默认上限为每秒14笔交易,节点主动发起的出站连接允许达到该速率的2.5倍。交易数据另有独立的带宽上限,即每10分钟12 MB,并配有更高的突发额度,让节点能够吸收短时尖峰,而不是一遇压力就丢弃数据。区块连接方式也随之改变。区块到达时,节点会从链状态数据库中预读此前的交易输出(prevouts),链状态数据库是记录每一笔未花费输出(包括隔离见证输出)的账本结构。多个工作线程并行读取这些条目,默认8个,上限16个。发行说明称,当数据必须从磁盘读取时,这一改动可以加快验证速度,但说明中未给出任何基准测试或分环境对比。快速验证关系到两类人:运行节点、逐块核验的运营者,以及候选区块需要被网络接受的矿工。

32系列首个实际可得的版本

32.1也是32系列中运营者真正能够下载安装的第一个版本。发行说明记录,32.0已打上代码标签,却从未正式公告或部署,走到公众面前的构建是32.1。与队列改动同步推进的还有网络层防御。Bitcoin Core自动生成的Tor隐藏服务,在Tor守护进程支持的情况下,现在会加入工作量证明防御,这种机制抬高了向服务发动洪泛攻击的成本。I2P正在逐步淘汰的老式ElGamal(type 0)加密方案,计划在第34版或之前移除,而使用极少的CJDNS,其支持与否仍在评估之中。安全公告晚一天到来。10月28日星期三发布的一份公告描述了Linux以外操作系统上的一条select()处理路径,该路径可能耗尽节点内存,严重程度定为中级,Linux节点不受影响。这一缺陷由自动化大语言模型分析发现,修复版本覆盖四条仍在维护的版本线:29.5、30.4、31.2和32.1。Bitcoin (BTC) Core的披露政策要求在漏洞公开之前,修复必须先抵达每一条受维护的大版本,公告正是按这一顺序执行。生态其他方面,此前有攻击者利用Liquid Network漏洞,通过Elements代码中的一个缺陷转出了4000枚锚定资产。围绕本次发布的更大背景是量子计算之争。草案BIP-361提出对现有ECDSA和Schnorr签名方案分阶段施加限制,附带的时限是条件性的,前提是该提案激活;激活日期与网络采纳均无定论。长期持有者在传统钱包中长期HODL的币,在这种转向下将面临迁移,Coinbase 10月13日发布的一篇工程文章就点出了这个悬而未决的问题,并主张过渡应当尽早启动,且可能耗时数年。本周三有一篇The Motley Fool的文章以这次软件更新和量子讨论为由给出买入理由;但发行说明描述的只是节点运维,BIP描述的只是一份草案,两者都没有分析比特币价格。

属于运维的版本,不是行情事件

把更新日志和安全公告放在一起看,这轮改动是基础设施维护,市场也应如此对待。共享队列和16个工作线程的上限只在峰值时兑现价值:若无此改动,内存压力和缓慢的磁盘会拖慢中继与验证,因此收益落在节点运营者身上,而不是交易屏幕上。更值得关注的是披露节奏本身:一个中级缺陷由自动化大语言模型分析发现,先在四条受维护版本线上完成修复,随后才公开。量子议题悬而未签,BIP-361仍是一份带条件时间表的草案,钱包迁移因此是一个规划问题,而非倒计时。16线程上限的用武之地,正是区块到达、区块链账本状态必须从存储读取的那些磁盘瓶颈时刻。