Bitcoin (BTC) Core 32.1が並列検証のワーカー上限を16に引き上げ

共有キューで混雑時の負荷を一元化

ビットコイン (BTC)のフルノード向けソフトウェアBitcoin Coreを開発するチームが、バージョン32.1の目玉に据えたのはキューの刷新だ。10月27日(火曜日)に公開された今回のリリースでは、ノードが取引をピアへ中継する方式が書き直された。従来は接続ごとに個別の送信用キューを保持していたが、ノード全体で単一の共有キューを参照する方式に切り替わっている。公式のリリースノートは、取引量が集中する時間帯にメモリーとCPUの消費を抑えられるとしている。なお、この共有はノード内部の話で、Bitcoinネットワーク全体が共通のキューで動くわけではない。フルノードはすべての取引とブロックを独自に検証する仕組みで、旧設計では接続1本ごとに取引の中継待ちバッファが確保されていたため、接続が増えるほど中継用メモリーが膨らんでいた。共有型ではこのコストをノード単位で一度にまとめられる。中継の上限値も明確な数字で示されている。取引中継のデフォルト上限は毎秒14件で、ノード自身が張るアウトバウンド接続にはその2.5倍が認められる。別途、取引データ用の帯域上限が10分あたり12MBと定められ、短期的なスパイクを最初の圧力で吐き出さずに吸収できるよう、一時的なバースト許容量はさらに高めに設定されている。ブロック接続の処理も変わる。ブロックが到着すると、ノードはすべての未使用出力を追跡するチェーンステートデータベースから、前段の取引出力(プレヴァウト)を先読みする。読み取り対象にはSegregated Witnessの出力も含まれ、複数のワーカーが並列に当該エントリを読み込む。デフォルトは8、上限は16だ。リリースノートは、データをディスクから読む場面で検証が速くなると述べるが、ベンチマークや環境別の比較は示していない。高速な検証は、ブロックを検証するノード運用者や、ネットワークに受け入れられる候補ブロックを提出するマイナーにとって実質的な意味を持つ。

32系で初めて出回る版に

バージョン32.1は、32系として運用者が実際に入手できる初のリリースでもある。32.0にはコードのタグが付けられたものの、公式発表も展開も行われなかったとリリースノートは記録しており、一般に届くビルドは32.1ということになる。キュー改良と並行して、ネットワーク防御も手が入った。Bitcoin (BTC) Coreが自動生成するTorの隠しサービスは、Torデーモンが対応している環境でプルーフオブワーク型の防御を備えるようになり、サービスへの大量送信攻撃のコストを引き上げる仕組みだ。一方、I2Pが段階的に廃止を進める旧式のElGamal(タイプ0)暗号は、バージョン34までに削除される予定だ。利用がほとんど見られないCJDNSへの対応は、継続が見直し中となっている。セキュリティ面の発表はその翌日だった。10月28日(水曜日)公開のセキュリティ勧告は、Linux以外のOSにおけるselect()の処理経路がノードのメモリーを使い果たし得ると説明し、深刻度は中と評価している。Linuxのノードは影響を受けない。この脆弱性はLLMによる自動解析から浮かび上がり、修正版は29.5、30.4、31.2、32.1のメンテナンス中の4系すべてに展開された。Bitcoin Coreの開示方針では、脆弱性の公開前にすべてのメンテナンス中のメジャーバージョンへ修正を届けることが求められており、勧告はこの順序に従った。エコシステムの他方では、Liquid NetworkのエクスプロイトがElementsの脆弱性を突き、4,000資産のペグアウトを引き起こしていたことが確認されている。今回のリリースを取り巻く文脈には、量子コンピュータへの備えを巡る議論もある。草案段階の提案BIP-361は、既存のECDSAとSchnorr署名方式の段階的な制限を描いており、時程表は提案が有効化されることを前提とした条件付きのものだ。有効化の時期もネットワーク側の採用も確定していない。こうした移行が実現すれば、レガシーウォレットで長期保有(いわゆるHODL)しているコインは移行を迫られる。10月13日に公開されたCoinbaseのエンジニアリング投稿は、この論点を指摘し、移行は早く始めるべきで数年を要し得ると論じた。水曜日にあるMotley Foolの記事は、今回のソフトウェア改善と量子議論を購入の根拠として挙げた。しかしリリースノートが記すのはノード運用であり、BIPが記すのはあくまで草案で、いずれもブロックチェーン市場でビットコインの価格を分析したものではない。

市場イベントではなく保守作業

変更履歴と勧告を並べて読めば、両者はインフラの保守作業を記述していることが分かる。市場はこの位置づけのまま扱ってよいはずだ。共有キューと16ワーカーの上限が効果を発揮するのはピーク時、すなわちメモリー圧迫や遅いディスクが中継と検証を遅らせ得る場面だけで、恩恵を受けるのはトレーディングの画面ではなくノード運用者だ。むしろ静かに進展したのは開示の進め方の方だ。中程度の深刻度の脆弱性をLLMによる自動解析で発見し、メンテナンス中の4系すべてに修正を展開した後に初めて公開する、という順序が今回も守られている。量子対策のファイルは未署名のまま残る。BIP-361はDraft状態で条件付きの時程表を示すにすぎず、それゆえウォレット移行は締め切りではなく計画段階の論点にとどまっている。16ワーカーという上限は、ブロック到着時にチェーンステートをストレージから読み込まざるを得ない、まさにそのディスク律速の場面のために存在する。