Block Header

ブロックを取引の詰まった荷物、ヘッダーをその添付記録と考えてみてください。ヘッダーに受取人や金額の一覧はありません。代わりに、データから計算した短い値である暗号学的な指紋があり、データの変更を検出できます。一つは前のブロックを指し、もう一つの Merkle root は、このブロック内の取引の識別子をまとめています。こうして特定の内容と履歴上の特定の位置が結びつきます。ただし、取引を小さくコピーしたものではありません。指紋から元の取引内容を読み戻すことはできません。 [1] [4]

採掘者はブロック候補を組み立て、条件を満たすハッシュを探します。ハッシュは数値として解釈される指紋で、決められた目標値以下でなければなりません。この探索が Proof of Work です。適切な結果を簡単には予測できないため、採掘者はデータを変えて計算を繰り返します。よく知られた変数は nonce というヘッダー内の補助的な数値です。さらに試す余地を作るため、ブロック先頭に作る特別な Coinbase Transaction のデータを変えることもできます。すると Merkle root も変わり、別のヘッダーになります。他のノードは、見つかった結果を短時間で再計算して確認できます。 [1] [3] [4]

ヘッダーの連なりを使えば、全取引をダウンロードせずにブロックのつながりや対応する計算作業を検証できます。しかし、有効な Proof of Work があるブロックの中で、誰かが必要な署名なしに他人の資金を使おうとしていたらどうでしょう。ヘッダーだけの確認では、その問題は見つかりません。そのため Full Node は、取引、署名、利用可能な未使用の出力、許される報酬も検証します。ヘッダーが有効でも、ブロック全体が有効とは限らないのです。 [2]

nBits フィールドはハッシュが満たすべき目標値を指定します。これは目標値のコンパクトな符号化であり、ブロックエクスプローラーが表示する「difficulty」の数値ではありません。ノードは、その目標値がチェーン上の位置に応じた規則に従っているかも確認します。採掘者は時刻も自由には選べません。直前の 11 ブロックの時刻を並べた中央の値、つまり中央値より後で、未来に進みすぎていてはいけません。それでも、各支払いの正確な時刻や採掘時間を測るストップウォッチではありません。 [2] [3]

フィールドの順序と大きさは固定です。version が 4 バイト、前のヘッダーのハッシュが 32 バイト、Merkle root が 32 バイト、time、nBits、nonce が各 4 バイトで、取引数に関係なく合計 80 バイトです。この決まった形式で符号化したヘッダーに SHA-256 を二度適用すると、ブロックの識別子が得られます。数値のフィールドは最下位バイトを先に置く little-endian を使います。ハッシュの内部のバイト順は、識別子の通常の表示順とは異なります。そのため、自分で計算する際にエクスプローラーの表示値をそのままつなげるだけでは正しい結果になりません。 [1] [4]