AssumeUTXO は、特定のブロックで保存された状態であるスナップショットを読み込み、Bitcoin ノードを早く利用可能にする方法です。ソフトウェアに組み込まれた、その状態の期待される指紋に一時的に依存します。後で自ら履歴を処理して結果を比較するため、スナップショットがその作業を不要にするわけではありません。
ペーターは初めての Full Node、つまり Bitcoin のルールを自分で検証するプログラムを起動します。ブロックは、共有する履歴に追加する取引のまとまりです。通常の起動では、まず長い履歴を処理しなければなりません。AssumeUTXO なら、準備済みの UTXO set から始められます。これはまだ使われていないトランザクション出力の集合で、各出力には金額と使用条件が記録されています。スナップショットは特定のブロックの後の状態です。全支払いの保存記録でも、彼のコンピューターが過去をすべて検証済みだという証拠でもありません。 [1] [3]
ファイル名だけでスナップショットを正しいと判断することはできません。loadtxoutset で読み込む際、Bitcoin Core v29.0 は形式、基準ブロック（スナップショットが対応するブロック）、対応するパラメーターを確認します。さらに UTXO の内容から暗号学的な指紋である hash を計算し、有効化する前に期待値と比較します。内容を書き換えたファイルは、信頼できそうな名前を付けただけでは検査を通りません。 [2] [3] [6]
スナップショットを受け入れると、ノードはその状態から続きを進め、後続ブロックを検証してチェーンの現在の末端に到達できます。無条件で受け入れるわけではなく、使用条件や新しいビットコインの許容発行量などを引き続き検査します。この経路は古い履歴の処理完了を待たずに現在の活動へ進めるのが利点です。ただし、それ以前の履歴がすでにローカルで検証されたことにはなりません。 [1] [6]
同時に、履歴の最初からスナップショットの基準ブロックまでを処理して、別の状態が作られます。これは履歴から独立して計算する作業であり、ダウンロードした一覧のコピーをもう一つ作ることではありません。そのため、一時的に進捗の異なる二つの状態が存在します。技術的なコマンド getchainstates で両方を確認できます。アクティブな状態が最新ブロックに到達しただけでは、バックグラウンド作業の完了は確認できません。 [1] [8]
期待される hash と対応する基準ブロックは、特定のソフトウェアバージョンに組み込まれています。ペーターのノードが自ら履歴を計算し終えるまでは、その情報が正しいという前提に依存します。hashを比較すると内容が一致するかを確認できますが、それだけで有効な履歴から得られた内容だと証明できるわけではありません。期待される状態が誤っていれば、早期利用もその誤った前提に基づきます。後の履歴検証と、読み込み時のファイル検査を区別する理由はここにあります。 [2] [6]
ファイルを別の運営者から入手しても、その人に受け入れる状態を決める権限が生まれるわけではありません。重要なのは提供者の約束ではなく、ソフトウェアが対応する値との一致です。また、どのブロックのどんなスナップショットでも読み込めるわけではなく、対応範囲はバージョンとネットワークで決まります。Hash の検査はファイルの配信自体を保証せず、取得や処理にかかる時間、通信量、ディスク容量もなくしません。 [2] [4] [7]
バックグラウンド処理が同じ基準ブロックに達すると、自分で構築した UTXO set の hash を計算し、期待されるスナップショットの hash と比べます。現在の状態と古い写真を比べるのではなく、履歴上の同じ地点を比較するのです。一致しなければ、ここで説明する実装はノードを停止し、スナップショットから作られた状態を使うのをやめます。不一致を隠したり、検証成功として報告したりはしません。 [1] [6]
AssumeUTXO が主に変えるのは、ノードを使い始められるまでの時間です。過去のダウンロードと検証は続き、一時的に状態データベースも二つ維持します。処理能力とディスクの読み書きが必要です。Pruned Nodeは、処理済みの古いブロックファイルを削除して容量を節約するノードで、ルールの検証を省くものではありません。Pruned Node でもスナップショットを使えますが、容量削減には別の制約があります。一部の補助索引は最初から履歴を処理するため、ノードが早く使えるようになっても、接続する全アプリが即座に準備完了とは限りません。 [5] [7]
UTXO set に入っているのは未使用出力の情報であり、支出を承認する秘密鍵ではありません。デジタル署名は、秘密の数値である秘密鍵を使って支払いの許可を証明し、鍵そのものは公開しません。UTXO setはウォレットのバックアップではなく、失った Seed Phrase、つまりこの復元方式を使うウォレットの復元用の単語も取り戻せません。古い支払いもすぐに表示されるとは限らず、検索にはスナップショット以前のブロックが必要なことがあります。鍵のバックアップ、自分のウォレット履歴の検索、ネットワーク状態の検証は別々の仕事です。 [1] [7]
似た名前は混同しがちです。AssumeUTXO は読み込んだ状態から始め、古い履歴をバックグラウンドで再構築します。一方の assumevalid は、特定の条件で過去のスクリプト検査、つまり署名を含む使用条件の検査の一部を省略できます。これは独立した最適化であり、履歴検証にも影響し得ます。AssumeUTXO が完了したことだけでは、それが無効だったとは分かりません。手順を読むときは、開始地点、実際に行う検査、各検査の終了時点を区別しましょう。 [5] [6]
理解を深めるには、この項目とあわせて次もお読みください Initial Block Download, Pruned Node, Block Propagation, Nakamoto Consensus, Bitcoin, Bitcoin Core. 次の項目からも参照されています Initial Block Download, Pruned Node, Utreexo.