ヘッダーチェーン

ノードは、信じているヘッダーと、保存しているブロック本体という2つを同時に追跡します。ヘッダーは1つあたり80バイトです。そのため1年分、およそ52,560ブロックで、約4.2MBになります。このサイズの差があるため、ウォレットは、特定のブロックの中身を知るよりはるかに早い段階で、チェーンの現在の高さと累積作業量の合計を知ることができます。

仕組み

ヘッダーチェーンは、含まれるブロックの数ではなく、累積プルーフ・オブ・ワークによって順序づけられます。

すべてのヘッダーは親を指定するため、ノードが把握しているヘッダーの集合は、線ではなく木を形成します。合計作業量が最も大きい枝が最良のヘッダーチェーンであり、ノードは、後に追い越す場合に備えて、敗れた枝も記憶します。Bitcoin Coreはこの木をブロックインデックスに保持します。これはblocks/indexディレクトリにある小さなLevelDBデータベースで、トランザクションを格納する生のブロックファイルとは完全に分離されています。

木が保持されているため、ノードは自身の不確実性を説明できます。getchaintipsコマンドは、把握しているすべての先端を状態付きで一覧表示します。追跡中の枝はactive、本体を一度も取得していない枝はheaders-only、競争に敗れた完全に検証済みの枝はvalid-fork、ルールに違反した枝はinvalidです。再編成とは、ブロックが揃った後にノードがこの木を横断してある先端から別の先端へ移ること以外の何ものでもありません。

ヘッダーは、ブロックデータが耐えられないものにも耐えます。プルーニングノードは容量を節約するために古いブロックファイルを削除しますが、prune=550というBitcoin Coreが受け付ける最小の設定でも、ジェネシスブロック以降のすべてのヘッダーを保持します。ヘッダーがなければ、新しいブロックがすでに受け入れたチェーンに積み重なっていることを確認できないため、ヘッダーは決して捨てられない部分です。

確認できる場所

ヘッダーチェーンは、ノードがどれだけ遅れているかを伝えるときに示す数値です。

getblockchaininfoを実行すると、blocksとheadersという2つのフィールドが得られます。headersは最良のヘッダーチェーンの高さ、blocksはそのうちダウンロードして完全に検証した部分であり、両者の差がまだ残っている作業です。同期済みのノードではこの2つが一致し、headersの値が止まっているノードは、単に遅いノードではなく、ピアとの接続を失ったノードです。

軽量ウォレットはそれ以外を保持しません。SPVウォレットやコンパクトフィルタクライアントはヘッダーのみを保存し、それを使って、関心のあるトランザクションが実際のプルーフ・オブ・ワークの下にあることを確認します。難易度もヘッダーから計算できます。ターゲットは2,016ブロックごとに、チェーンにすでにあるタイムスタンプとnBitsの値だけを使ってリセットされるため、クライアントはトランザクションを一度も見ることなく、数えている作業が本物であることを検証できます。

ヘッダーチェーンvsブロックヘッダー

ブロックヘッダーは80バイトの単一のレコードであり、ヘッダーチェーンはそれらすべてが2009年1月3日のジェネシスブロックまで連なるものです。この区別は、ライトクライアントがプルーフ・オブ・ワークを検証すると誰かが言うときに重要になります。1つのヘッダーは、1つのブロックの生成にコストがかかったことを証明します。それらが連なり、それぞれが親を確定させることによってのみ、特定のブロックが、誰にも静かに置き換えられていない途切れのない高コストの作業の連鎖の後ろにあることが証明されます。