隠蔽されたビットコインノードデータベースは40 GB縮小しましたが、それはランナーが再構築した場合に限ります

Bitcoin Core は、オプションのトランザクションインデックスの再設計を統合し、ある貢献者のメインネットテストでデータベースから約 40 GB を削減しました。使用する演算子 -txindex アップグレードを通じて既存のインデックスを保持します。完全な保存をキャプチャするには、データベースを再作成する必要があります。

8 月 15 日に Bitcoin Core のマスターブランチにマージされたプルリクエスト #35531 により、作成者が再構築したメインネット txindex が約 66 GB から 26 GB に減少しました。約 61% の削減は、このオプションのインデックスに限定されます。ビットコインのブロックチェーンとノードのデータディレクトリの残りの部分は測定の対象外のままです。

コードは上流でマージされます。安定したバイナリは別のリリースプロセスに従い、ビットコインコアのリリースインデックスでは、変更が含まれる最初のバージョンは未指定のままになります。オペレータは、それを出荷するリリースの移行ノートが必要になります。

小さいインデックスの仕組み

ビットコインコアの -txindex このオプションは、完全なトランザクション ID によってトランザクションを取得するためのデータベースを維持します。古い形式では、32 バイトの各トランザクション ID がトランザクションディスク位置データとともにデータベースキーとして保存されていました。

再設計では、はるかに短いルックアップキー、つまりソルトされた SipHash から派生した 5 バイトのプレフィックスと、それに続くブロックシーケンスとトランザクションオフセットをエンコードする 6 バイトのサフィックスが格納されます。 Bitcoin Core が一致を返す前に、完全なトランザクション ID が引き続きチェックされます。

この検証手順により、短いプレフィックスによって発生する衝突が防止されます。 Bitcoin Core は、プレフィックスを共有するエントリをスキャンし、ブロックインデックスを通じて候補ブロックを見つけ、ディスクから候補トランザクションを読み取り、完全な ID を比較します。 Bitcoin Optech の技術概要では、衝突は追加の読み取りおよび検証作業であり、フル ID チェックにより誤ったトランザクションの一致を防止すると説明されています。

著者のテストではパフォーマンスは安定していました。ルックアップには約 0.2 ミリ秒かかりました。メインネットの再構築は、以前の形式では 1 時間 50 分であったのに対し、1 時間 19 分で完了しました。ハードウェア、ストレージ、チェーンの高さ、ソフトウェアのバージョンによって結果が変わる可能性があります。

既存の txindex データベースはアップグレード後も読み取り可能な状態を維持するため、即時の強制的な再構築が回避されます。従来のエントリもより大きなフットプリントを維持するため、ベンチマークを完全に 40 GB 節約するには、インデックスを再作成する必要があります。

その後のダウングレードには 2 番目の移行コストがかかります。 Bitcoin Core のマージされたリリースノートの断片には、以前のリリースではコンパクト形式で書かれたエントリを読み取ることができないと記載されています。再構築後に古いリリースに戻すと、古い形式での txindex の再構築が再度トリガーされます。

オペレータの利益は、その狭い範囲内でかなりのものです。つまり、オプションのインデックスがはるかに小さくなり、貢献者のテストでの再構築が高速化されます。これをキャプチャするには、データベースを計画的に再作成する必要があり、ロールバックが必要になった場合は再度再構築する必要があります。

リリース固有のメモでは、変更が安定した Bitcoin Core バイナリに到達した後の正確な再作成とダウングレードの手順を制御する必要があります。