昨日、Bitcoin Core（公式版Bitcoinクライアント）の最新版、v0.11.0のRC1（リリース候補）がリリースされました（Bitcoin開発者ML内の告知メール）。

まだリリース候補という状態ではありますが、次期バージョンで導入される予定となっている機能がいくつか含まれていますので、 主だった変更点を紹介していこうと思います。

なお、まだテスト待ちの段階ですので、今後いくつか変更がなされる可能性があることに注意しておきます。

後方互換生

v0.10にて導入されたヘッダ優先同期・ブロックの並列ダウンロード機能 (headers-first synchronization and parallel block download) の影響で、 v0.9系統およびそれ以前のバージョンからアップグレードする場合には後方互換性がなくなり、ダウングレードが不可能となっておりますので引き続き注意が必要です。

v0.10系統からアップグレードされる方は特に後方互換生の影響は確認されていませんので、特に問題なくダウングレードできるはずです。

主要変更点

ブロックファイル剪定 (pruning) モード

いままでのBitcoin Coreではすべてのブロックデータ（内包されているトランザクションデータを含む）および、 巻き戻し用データを保持していたため、何十GBにも及ぶHDD容量を消費していました。

この剪定モードを有効にすると、古いブロックデータやトランザクションが自動的に捨てられるようになりますので、HDD容量を節約することができます。

剪定モードを有効化するには -prune=N オプションを指定します。 ここで N は保持するデータの上限値（MiB単位^[1]）です。

剪定モードはデフォルトで無効です。

• Bitcoin Coreの保持する主なデータのうち「生のブロックデータ (blocks/blk*.dat)」および「巻き戻し用データ (undo data; blocks/rev*.dat)」は剪定対象ですが、「ブロックのインデックスデータ (blocks/index/*)」および「UTXO (chainstate/*)」は剪定対象外であり、後者のデータサイズは削減されません
• 剪定は、ブロックデータの最大容量を指定することで行われます。ブロックデータがこの最大容量を超過した場合に古い順にブロックデータおよび巻き戻し用データが削除されます
  • ただし、少なくとも最新の288ブロック（約二日分）のデータは必ず保持するようになっており、これらのブロックの剪定は行われません
• 現在のところ、剪定モードのノードはブロックデータのリレーは行いません。しかしながら将来のリリースではそのノードの保持している最新のブロックデータのみリレーするように改良する予定です
• 現在のところ、ウォレット機能が有効化されている場合には剪定モードは有効化できません。これは各アドレスの未使用トランザクション出力が剪定対象のブロックに入っていた場合にうまく動作できないからですが、将来のリリースでは改良予定です
• -txindex (トランザクションのインデックス作成) オプションが有効になっている場合には剪定モードは利用できません
• すでに剪定されてしまったブロックの状態まで遡るためには、ブロックチェイン全体を再ダウンロードする必要があります。また、データ破損等によりブロックデータの再読み込みが必要となった場合にも同様にブロックチェイン全体の再ダウンロードが必要となります
• getblockchaininfo, getblock, getrawtransaction RPCコマンドの挙動や出力が変更されます

現状のコードでは「ウォレット機能が使えない」「ブロックデータのリレーは行わない」という仕様になっていますのであまり使いどころはなさそうですが、 すべてのトランザクションやブロックデータを検証するノードではありますので、例えば「入金トランザクションの正当性を最も安全に検証できるサーバ」を構築するのには使えそうです。

今後の機能追加に期待しましょう。

※「prune = 剪定」という訳語を当てていますが、あまり適切ではないと思っておりますので、ご意見のある方はコメントをいただければと思います。 なお、Bitcoin Core v0.11の翻訳はほぼすべて著者が行っておりますので、こちらの翻訳もすべて「剪定」になっているはずです。

ビッグエンディアン環境のサポート

※「エンディアン」についてはWikipediaの記事をご覧ください。

いままではIntel CPUなど、現在多くのCPUで採用されているリトルエンディアン方式のCPUでのみ動作するコードになっており、 PowerPCや一部のスパコンなどビッグエンディアンを採用しているシステムでは動作しませんでした。

本リリースよりエンディアン中立なコードが実験的に追加されました。

こちらは多くの方には影響のないものと思いますが、ビッグエンディアンなシステムをお持ちの方はできればテストをし、報告をしましょう。

メモリ使用量の最適化

本リリースでは多くのメモリ使用量最適化に関する変更がなされています。 そのうちいくつかを紹介します。

• UTXOキャッシュサイズの推定が正確になり、-dbcache オプションがより正確になりました
• ピア情報の格納サイズが削減され、同一メモリ容量でより多くのピアと接続できるようになりました
• スレッド数が削減され、メモリ要求量が削減されました

プライバシー：ウォレットトランザクションのブロードキャスト無効化機能

ウォレット内で新たに生成・電子署名がなされたトランザクションの自動ブロードキャストおよび、再ブロードキャスト機能を -walletbroadcast=0 オプションにより無効化できるようになりました。

Bitcoinネットワークを監視することにより、どのノードが一番初めにトランザクションをブロードキャストしたのかがバレてしまい、 どのノードがどのアドレスの秘密鍵を持っているのかがバレてしまう可能性がありました。

この機能を利用することで、電子署名を行うノードと、トランザクションのブロードキャストをするノードを分離することができますので、 リリースノートで示されているようにトランザクションのブロードキャストのみをTor経由で行うことでプライバシーを向上させることができます。

プライバシー：Tor利用時のピア毎の接続回路生成

Torを利用した場合に、接続回路（エントリー、中継、イグジットといったノードをどう選択するか）を接続するピアごとに生成する -proxyrandomize オプションが導入されました。 このオプションはデフォルトで有効です。

これによりピアごとに異なるイグジットノードが選択されることが期待できますので、 運悪く悪意のある、もしくはP2Pネットワークからbanされている単一のイグジットノードが選択されてしまう確率を低減できます。 これにより、特に初期接続時における安定性やプライバシーを向上させることができると期待できます。

ただし、Tor以外のSOCKS5プロキシが設定されている場合には、副作用により接続に失敗することがあります。 そのような場合には -proxyrandomize=0 オプションを指定し、この機能を無効化してください。

なお、リリースノートには明記されていませんが、 これら二つのプライバシーに関する変更はTorを用いたとしても完全なプライバシーを保つことができない、という研究結果などにもとづいていると考えられますので、 ご興味がありましたらリンク先の論文もご覧いただければと思います。

情報源

• v0.11リリースノート（最新コミット）

---