比特幣區塊結構深度技術解析：從區塊頭到 Merkle Tree 的完整工程視角

概述

比特幣區塊是比特幣區塊鏈的基本儲存單位，每個區塊由區塊頭（Block Header）和區塊體（Block Body）兩部分組成。區塊頭大小固定為 80 位元組，是工作量證明計算的核心對象，也是輕錢包驗證區塊存在性的關鍵資料結構。理解比特幣區塊結構對於比特幣開發者、安全審計人員、以及希望深入理解比特幣共識機制的讀者至關重要。本文從工程師的視角出發，詳細剖析每個欄位的二進制表示、協議約束、以及與共識安全的關聯。讀者需具備基本的密碼學知識與資料結構基礎。

區塊結構總覽

區塊的基本構成

比特幣區塊由以下兩部分組成：

區塊頭的固定 80 位元組結構

┌─────────────────────────────────────────────────────────────────────────────┐
│                           區塊頭結構 (80 bytes)                               │
├──────────┬────────────┬─────────────────────┬──────────┬──────────┬─────────┤
│ Version  │ Previous   │ Merkle Root         │ Timestamp│  Bits    │ Nonce   │
│ (4 B)    │ Block Hash │ (32 B)              │ (4 B)    │ (4 B)    │ (4 B)   │
│          │ (32 B)     │                     │          │          │         │
└──────────┴────────────┴─────────────────────┴──────────┴──────────┴─────────┘

版本號欄位 (Version)

資料表示

版本號是一個 4 位元組的小端序（Little Endian）無符號整數，目前主流值為 0x20000000（十進位 536870912）。

版本號的歷史演變

Version Bits 機制

從 BIP-9 開始，比特幣使用 version bits 機制進行軟分叉升級。版本號的 29-32 位（第 3 個位元組的低 3 位）用於指示即將啟動的改進提案。

版本號二進位分析：
0x20000000 = 0010 0000 0000 0000 0000 0000 0000 0000
                     ^^^^^
                     這些位用於 version bits

版本號計算方式：
version = 0x20000000 | (candidate_id << 29) | (transition_bit << 28)

Example (SegWit 啟動):

# BIP-9 啟動參數
def calculate_version_for_bip9(chain_start_time, timeout, bit):
    """
    計算軟分叉啟動的版本號
    """
    # version = 0x20000000 + (bit << 24) + (timeout << 26)
    # 其中 bit 是 0-28 的整數
    # 這裡的計算需要根據具體實現
    pass

# SegWit 的 version bits 使用 bit 0
# 因此版本號可能是 0x20000001 (bit 0 = 1)

軟分叉啟動的版本號模式

前區塊哈希 (Previous Block Hash)

資料表示

這是一個 32 位元組（256 位）的 SHA-256d 哈希值，指向區塊鏈中前一區塊的區塊頭哈希。創世區塊（Genesis Block）作為第一個區塊，其 previous block hash 為 32 個零位元組：

0000000000000000000000000000000000000000000000000000000000000000

創世區塊的硬編碼

比特幣節點軟體中硬編碼了創世區塊的完整內容。以下是 Bitcoin Core 中的創世區塊定義：

// bitcoin/src/chainparams.cpp
consensus.hashGenesisBlock = uint256S("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f");

創世區塊的區塊頭哈希（區塊 #0）：

0000000000000000000000000000000000000000000000000000000000000000
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

區塊鏈的不可變性保證

previous block hash 欄位形成了區塊之間的密碼學連結，這是比特幣區塊鏈不可篡改特性的核心：

Block N 的 header 包含：
previous_block_hash = SHA-256d(Block N-1 的 header)

如果攻擊者修改 Block N-1 的內容：
1. Block N-1 的 header 哈希改變
2. Block N 的 previous_block_hash 不再匹配
3. 需要重新計算 Block N 的工作量證明
4. 依此類推，需要重新計算後續所有區塊的工作量證明

篡改代價的量化分析：

假設要修改 10 個區塊以前的交易：

• 需要重新計算 10 個區塊的工作量證明
• 以 2024 年 3 月的全網算力約 600 EH/s 計算
• 每個區塊平均需要 10 分鐘
• 總耗時 ≈ 10 × 10 分鐘 = 100 分鐘
• 這在實際上是不可行的

Merkle 根 (Merkle Root)

資料結構原理

Merkle 根是區塊中所有交易構成的 Merkle 樹的根節點值，提供以下關鍵功能：

1. 交易承諾 (Transaction Commitment): 承諾特定交易集合的存在
2. 高效驗證 (Efficient Verification): 可在 O(log n) 時間內驗證交易存在性
3. 空間效率 (Space Efficiency): 僅需 32 位元組即可承諾任意數量交易

Merkle 樹的建構演算法

步驟 1: 計算每筆交易的哈希值（交易 ID）
        TX0 hash = SHA-256d(TX0)
        TX1 hash = SHA-256d(TX1)
        TX2 hash = SHA-256d(TX2)
        TX3 hash = SHA-256d(TX3)
        ...

步驟 2: 兩兩配對，計算父節點哈希
        Parent0 = SHA-256d(TX0_hash || TX1_hash)
        Parent1 = SHA-256d(TX2_hash || TX3_hash)
        ...

步驟 3: 重複步驟 2 直到只剩一個根節點
        Root = SHA-256d(Parent0 || Parent1)

步驟 4: 若節點數為奇數，最後一個節點與自身配對
        若有 3 個節點：H1 || H2, H3 || H3

Merkle 樹的視覺化示例

假設區塊包含 4 筆交易：

                    ┌─────────────────────────────────────┐
                    │           Merkle Root                │
                    │     (32 bytes, 256 bits)            │
                    └─────────────────────────────────────┘
                    /                                   \
        ┌───────────────────────┐           ┌───────────────────────┐
        │      Parent Node 0     │           │      Parent Node 1     │
        │     (32 bytes)         │           │     (32 bytes)         │
        └───────────────────────┘           └───────────────────────┘
        /                \                       /                \
┌─────────────┐   ┌─────────────┐     ┌─────────────┐   ┌─────────────┐
│   TX0 Hash  │   │   TX1 Hash  │     │   TX2 Hash  │   │   TX3 Hash  │
│  (32 bytes) │   │  (32 bytes) │     │  (32 bytes) │   │  (32 bytes) │
└─────────────┘   └─────────────┘     └─────────────┘   └─────────────┘

奇數交易的處理

若交易數量為奇數，最後一筆交易會與自身配對：

假設有 5 筆交易：
TX0, TX1, TX2, TX3, TX4

建構方式：
Level 0: H0, H1, H2, H3, H4
Level 1: H0 || H1, H2 || H3, H4 || H4  ← 最後一筆複製
Level 2: H01 || H23, H44 || H44        ← 繼續配對
Level 3: H0123 || H4444                 ← Merkle Root

交易存在性驗證 (Merkle Proof)

Merkle Proof 允許輕節點驗證特定交易存在於區塊中，無需下載所有交易：

def verify_merkle_proof(txid, proof_hashes, proof_indices, merkle_root):
    """
    驗證交易存在性
    
    參數:
        txid: 要驗證的交易哈希
        proof_hashes: 沿途需要配對的哈希值列表
        proof_indices: 對應哈希在每層的位置（用於確定左右配對）
    
    返回:
        bool: 是否驗證成功
    """
    current = txid
    
    for i, (sibling_hash, is_left) in enumerate(zip(proof_hashes, proof_indices)):
        if is_left:
            current = sha256d(current + sibling_hash)
        else:
            current = sha256d(sibling_hash + current)
    
    return current == merkle_root

SPV 錢包的驗證效率

SPV 錢包只需下載區塊頭（約 80 bytes/區塊），加上目標交易的 Merkle Proof，即可驗證交易已被確認。

時間戳 (Timestamp)

資料表示

時間戳是一個 4 位元組的小端序無符號整數，表示 Unix Epoch 以來的秒數。

# 解析區塊時間戳
import struct
import datetime

def parse_block_timestamp(timestamp_bytes):
    """解析 4 位元組時間戳"""
    timestamp = struct.unpack('<I', timestamp_bytes)[0]
    dt = datetime.datetime.fromtimestamp(timestamp, tz=datetime.timezone.utc)
    return timestamp, dt

# 區塊 #840000 (2024年減半區塊) 的時間戳約為 1713283200
# 轉換為 UTC: 2024-04-20 03:00:00

共識約束

比特幣對時間戳有兩個重要約束：

約束 1: 不能過早

timestamp > median_time_past (MTP)

mediantimepast 是前 11 個區塊時間戳的中位數。這確保了時間戳反映了網路的歷史共識。

約束 2: 不能過晚

timestamp < current_time + 2 hours

這是一個網路時間策略限制，防止礦工填入過大的未來時間戳來獲得不正當優勢。

時間戳的重要性

1. 難度調整: 難度目標根據實際區塊時間與預期時間（10 分鐘/區塊）的偏差進行調整
2. 交易有效期: 某些交易類型（如 nLocktime）依賴區塊時間戳
3. 序號鎖定: 時間鎖（CLTV, CSV）使用區塊高度或時間戳作為觸發條件

難度目標 (Bits/Difficulty Target)

資料表示

Bits 是一個 4 位元組的壓縮格式，表示工作量證明的目標閾值。這種表示法節省空間，同時允許大範圍的目標值。

壓縮格式解析

Bits 格式: [exponent][coefficient]
           1 byte   3 bytes

解析公式:
Target = coefficient × 2^(8 × (exponent - 3))

其中:
- exponent: 0x18 到 0x1d (24-29) 是常見範圍
- coefficient: 有效範圍 0x008000 到 0x007fffff

實際解析示例

def parse_bits(bits_bytes):
    """解析 bits 欄位，返回目標值"""
    bits = int.from_bytes(bits_bytes, 'little')
    
    exponent = bits >> 24
    coefficient = bits & 0x007fffff
    
    target = coefficient << (8 * (exponent - 3))
    return target

# 創世區塊 bits: 0x1d00ffff
# exponent = 0x1d = 29
# coefficient = 0x00ffff = 65535
# Target = 65535 × 2^(8 × (29 - 3)) = 65535 × 2^208

# 2024年某區塊 bits: 0x170a5c28
# exponent = 0x17 = 23
# coefficient = 0x0a5c28 = 678568
# Target = 678568 × 2^(8 × 20) = 678568 × 2^160

難度目標的實際數值

工作量證明的有效性判斷

礦工找到的區塊頭哈希必須小於等於目標值：

BlockHash = SHA-256d(BlockHeader) ≤ Target

這是比特幣共識的核心——找到滿足條件的隨機數（nonce）需要消耗大量計算資源。

隨機數 (Nonce)

資料表示

Nonce 是一個 4 位元組的小端序無符號整數，範圍從 0 到 2^32 - 1（4294967295）。

挖礦過程

For nonce = 0 to 2^32 - 1:
    BlockHeader = version + prev_hash + merkle_root + timestamp + bits + nonce
    If SHA-256d(BlockHeader) < Target:
        找到有效的區塊！
        Broadcast block
        Break

ASIC 時代的 Extra Nonce

隨著 ASIC 礦機的普及，4 位元組的 nonce 空間在 10 分鐘內被快速搜尋完。為了解決這個問題，礦工使用「Extra Nonce」技術：

Extra Nonce 位址:
1. Coinbase 交易中的 OP_RETURN 欄位
2. Coinbase 交易的輸入序列號

原理:
改變 Coinbase 交易的內容 → 改變 Merkle Root → 改變區塊頭哈希

這允許礦工在不改變硬體的情況下，獲得近乎無限的搜索空間。

Extra Nonce 的實現

def mining_loop(coinbase_preimage, extra_nonce_start, target):
    """
    使用 Extra Nonce 的挖礦迴圈
    
    coinbase_preimage: Coinbase 交易的前半部分
    extra_nonce_start: Extra Nonce 的起始位置
    target: 難度目標
    """
    nonce = 0
    extra_nonce = extra_nonce_start
    
    while True:
        # 組合 coinbase 交易
        coinbase = build_coinbase(coinbase_preimage, extra_nonce)
        
        # 計算 Merkle 根
        merkle_root = build_merkle_tree(coinbase, other_transactions)
        
        # 嘗試所有 32 位 nonce
        for nonce in range(0, 2**32):
            header = build_header(
                version=0x20000000,
                prev_block=prev_block_hash,
                merkle_root=merkle_root,
                timestamp=current_time,
                bits=current_bits,
                nonce=nonce
            )
            
            hash_result = sha256d(header)
            if hash_result < target:
                return header, hash_result, nonce, extra_nonce
        
        # 用完 32 位 nonce，增加 extra nonce
        extra_nonce += 1

區塊體結構

交易的序列化格式

區塊體包含區塊中所有的交易，以比特幣網路協定定義的格式序列化。

區塊體格式:
┌────────────────────────────────────────────────────────────────────┐
│  [varint] Transaction Count                                        │
├────────────────────────────────────────────────────────────────────┤
│  Transaction 1 (完整序列化格式)                                      │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │ [4B] Version | [varint] Input Count | [36B] Previous Output   │  │
│  │ [varint] Script Length | [varint] Script | [4B] Sequence      │  │
│  │ [varint] Output Count | [8B] Value | [varint] Script Length   │  │
│  │ [varint] Script | [4B] Locktime                              │  │
│  └──────────────────────────────────────────────────────────────┘  │
├────────────────────────────────────────────────────────────────────┤
│  Transaction 2 ...                                                  │
├────────────────────────────────────────────────────────────────────┤
│  Transaction N                                                     │
└────────────────────────────────────────────────────────────────────┘

Coinbase 交易的特殊性

區塊的第一筆交易稱為 Coinbase 交易，是礦工的區塊獎勵：

# Coinbase 交易的特殊欄位
coinbase_tx = {
    'version': 1,
    'input': {
        'prev_output': b'\x00' * 36,  # 全零表示 coinbase
        'script': b'\x03' + block_height.to_bytes(3, 'little') + extra_nonce,
        'sequence': 0xffffffff
    },
    'output': {
        'value': block_reward + total_fees,
        'script': miner_payout_script  # P2PKH, P2WPKH, etc.
    },
    'locktime': 0
}

Coinbase 資料的重要用途:

1. Extra Nonce: 提供額外的搜索空間
2. Commit Messages: 中本聰在創世區塊的 Coinbase 中嵌入《泰晤士報》頭版標題
3. 防範 Replay Attack: 隔離見證（SegWit）升級期間，使用 Marker 和 Flag 防止交易重放

隔離見證的區塊格式

BIP-141 引入隔離見證（Segregated Witness）後，區塊結構發生了變化：

SegWit 區塊格式:
┌────────────────────────────────────────────────────────────────────┐
│  區塊頭 (80 bytes) - 不變                                            │
├────────────────────────────────────────────────────────────────────┤
│  [varint] Transaction Count                                         │
├────────────────────────────────────────────────────────────────────┤
│  交易 1 (Coinbase) - 包含 witness Commitment (若有)                  │
├────────────────────────────────────────────────────────────────────┤
│  交易 2-N (正常格式，但 witness data 移到 witness 欄位)              │
└────────────────────────────────────────────────────────────────────┘

Witness 結構 (每筆交易):
┌────────────────────────────────────────────────────────────────────┐
│  [varint] Witness Item Count                                        │
├────────────────────────────────────────────────────────────────────┤
│  [varint] Witness Item 1 Length                                    │
│  [bytes] Witness Item 1 (簽名數據等)                                │
├────────────────────────────────────────────────────────────────────┤
│  [varint] Witness Item 2 Length                                    │
│  [bytes] Witness Item 2                                            │
└────────────────────────────────────────────────────────────────────┘

Witness Commitment 的計算

SegWit 區塊中的 Coinbase 交易包含 Witness Commitment：

def calculate_witness_commitment(witness_root, witness_reserved):
    """
    計算 SegWit Witness Commitment
    
    BIP-141 定義:
    Witness Commitment = SHA256(
        SHA256(witness_root || witness_reserved)
    )
    """
    witness_root_hash = calculate_merkle_root_witness(transactions)
    
    data = witness_root_hash + witness_reserved
    hash1 = sha256d(data)
    hash2 = sha256d(hash1)
    
    # Witness Commitment 以 OP_RETURN 80 bytes 0xaa21a9ed 開頭
    commitment = bytes([0x6a, 0x20]) + hash2
    
    return commitment

# Witness Reserved 值由 BIP-147 定義
WITNESS_RESERVED = 0x0000000000000000000000000000000000000000000000000000000000000000

區塊傳播與 compact block

傳統區塊傳播的問題

在傳統傳播機制中，完整節點需要下載並驗證整個區塊。對於一個 2MB 的區塊，這涉及：

1. 接收完整的區塊資料
2. 驗證每筆交易的簽名
3. 重新計算 Merkle 根
4. 驗證工作量證明

這導致區塊傳播延遲，可能造成臨時的分叉。

BIP-152 Compact Blocks

BIP-152 引入了 Compact Blocks 協定，大幅減少區塊傳播所需的頻寬：

Compact Block 格式:
┌────────────────────────────────────────────────────────────────────┐
│  [80B] Block Header                                                │
│  [varint] Transaction Count                                        │
│  [1B] Short IDs 數量                                               │
├────────────────────────────────────────────────────────────────────┤
│  [6B each] Short Transaction IDs                                   │
├────────────────────────────────────────────────────────────────────┤
│  [varint] 區塊中包含的完整交易數量                                   │
├────────────────────────────────────────────────────────────────────┤
│  [variable] 區塊中包含的完整交易（少量）                             │
└────────────────────────────────────────────────────────────────────┘

Short ID 的計算方式:

def calculate_short_id(wtxid, wtxid_prefix):
    """
    BIP-152 Short ID 計算
    
    Short ID = sip_hash(wtxid, salt) mod 2^64
    其中 salt = block_hash XOR high_4_bytes_of(shorttxidki)
    """
    salt = xor(block_hash[:4], shorttxidki[:4])
    short_id = sipmod(wtxid, salt, 2**64)
    return short_id

區塊傳播效率提升

區塊大小與擴展限制

區塊大小的歷史演變

見證數據折算 (Witness Discount)

SegWit 將見證數據的權重設為 1，而不是普通交易的 4：

SegWit 區塊權重計算:
Weight = (Base Size) × 3 + (Total Size)
       = (non-witness data) × 4 + (witness data) × 1

其中:
- Base Size: 不包含見證數據的位元組數
- Total Size: 包含所有數據的位元組數
- Weight: 權重用於區塊大小限制

最大權重: 4,000,000 weight units (4 MWU)

交易大小的計算

def calculate_transaction_weight(tx):
    """
    計算交易的權重
    """
    base_size = len(tx.serialize_without_witness())
    total_size = len(tx.serialize())
    witness_size = total_size - base_size
    
    weight = base_size * 4 + witness_size * 1
    vsize = (weight + 3) // 4  # 向上取整到整數
    
    return weight, vsize

def calculate_block_weight(transactions):
    """
    計算區塊的總權重
    """
    total_weight = 0
    for tx in transactions:
        total_weight += calculate_transaction_weight(tx)[0]
    
    return total_weight

# 區塊有效性檢查
assert calculate_block_weight(block.transactions) <= 4_000_000, "區塊超重"

Taproot 的權重優化

Taproot (BIP-340/341/342) 進一步優化了見證數據的效率：

Taproot 交易權重:
- P2TR 輸入: 58.5 vbytes (Base) + witness size
- 簽名大小: 64 bytes (BIP-340 Schnorr)
- 對比 P2WPKH: 107.5 vbytes (67.5 vbytes + 40 bytes witness)

權重節省: 約 40-50%

區塊驗證的完整流程

從網路接收到區塊入鏈

步驟 1: 接收區塊資料
┌────────────────────────────────────────────────────────────────────┐
│  1.1 接收 inv 消息，請求區塊                                         │
│  1.2 接收區塊的完整資料或 compact block                              │
│  1.3 驗證網路傳輸完整性 (校驗和)                                     │
└────────────────────────────────────────────────────────────────────┘

步驟 2: 基礎格式驗證
┌────────────────────────────────────────────────────────────────────┐
│  2.1 解析區塊頭（80 bytes）                                          │
│  2.2 驗證區塊頭大小                                                   │
│  2.3 驗證版本號格式                                                  │
│  2.4 驗證 Previous Block Hash 格式                                  │
│  2.5 驗證 Merkle Root 格式                                          │
│  2.6 驗證時間戳範圍                                                  │
│  2.7 驗證 Bits 格式                                                  │
└────────────────────────────────────────────────────────────────────┘

步驟 3: 工作量證明驗證
┌────────────────────────────────────────────────────────────────────┐
│  3.1 計算 SHA-256d(BlockHeader)                                     │
│  3.2 解析 Bits 為 Target                                            │
│  3.3 驗證: BlockHash ≤ Target                                       │
│  3.4 這是最關鍵的安全性檢查                                          │
└────────────────────────────────────────────────────────────────────┘

步驟 4: 時間戳驗證
┌────────────────────────────────────────────────────────────────────┐
│  4.1 計算 Median Time Past (MTP)                                    │
│  4.2 驗證: timestamp > MTP                                          │
│  4.3 驗證: timestamp < network_time + 2 hours                       │
└────────────────────────────────────────────────────────────────────┘

步驟 5: 交易驗證
┌────────────────────────────────────────────────────────────────────┐
│  5.1 驗證第一筆是 Coinbase交易                                       │
│  5.2 驗證 Coinbase 的 Extra Nonce (若需要)                          │
│  5.3 驗證交易數量 > 0                                                │
│  5.4 驗證每筆交易的輸入/輸出有效性                                   │
│  5.5 驗證所有簽名 (隔離見證需特殊處理)                                │
└────────────────────────────────────────────────────────────────────┘

步驟 6: Merkle 樹驗證
┌────────────────────────────────────────────────────────────────────┐
│  6.1 重新計算所有交易的哈希                                          │
│  6.2 重新計算 Merkle 樹                                              │
│  6.3 驗證計算結果 == 區塊頭中的 Merkle Root                          │
└────────────────────────────────────────────────────────────────────┘

步驟 7: 共識規則驗證
┌────────────────────────────────────────────────────────────────────┐
│  7.1 驗證區塊獎勵 = subsidy + fees                                   │
│  7.2 驗證區塊不包含 double spend                                    │
│  7.3 驗證隔離見證 commitment (若為 SegWit 區塊)                     │
│  7.4 驗證其他共識規則                                                 │
└────────────────────────────────────────────────────────────────────┘

步驟 8: 連接到主鏈
┌────────────────────────────────────────────────────────────────────┐
│  8.1 驗證 previous block hash 指向已知區塊                            │
│  8.2 選擇最長鏈作為主鏈                                               │
│  8.3 若有分叉，根據工作量選擇主鏈                                     │
│  8.4 通知網路新區塊                                                    │
└────────────────────────────────────────────────────────────────────┘

驗證時間複雜度分析

區塊結構的安全性分析

區塊頭的安全性

區塊頭作為工作量證明的目標對象，其安全性由密碼學哈希函數的抗碰撞性保證：

攻擊區塊頭的代價:
1. SHA-256d 的抗碰撞攻擊: O(2^128) 次運算
2. 實用攻擊: 需要控制全網 51% 算力
3. 碰撞攻擊: 即使找到碰撞區塊頭，仍需滿足工作量證明條件

區塊體的安全考量

區塊體（交易）通過 Merkle 根與區塊頭連結。任何交易修改都會導致 Merkle 根變化，從而使工作量證明失效。

51% 攻擊與區塊重組

攻擊者可以:
1. 阻止特定交易確認
2. 逆轉自己的交易 (double spend)
3. 審查特定地址的交易

攻擊者不能:
1. 偷取他人的比特幣（無私鑰）
2. 改變比特幣的總量上限
3. 偽造不存在的比特幣

區塊結構與 Layer 2 的關係

比特幣主鏈的結算角色

Layer 2 解決方案（如閃電網路）的安全性依賴於比特幣主鏈的不可變性：

Layer 2 → 主鏈依賴:
1. 開啟通道: 在主鏈鎖定資金
2. 中間狀態: 可選地在主鏈發布處罰交易
3. 關閉通道: 結算到主鏈
4. 爭議處理: 主鏈作為仲裁者

Commitment Transaction 與區塊結構

閃電網路的 commitment 交易使用比特幣的腳本語言：

# 簡化的 commitment 交易腳本邏輯
commitment_script = """
IF
    # 延遲索回（對手延時後可提款）
    <delay_blocks> OP_CHECKSEQUENCEVERIFY OP_DROP
    <revocation_pubkey> OP_CHECKSIG
ELSE
    # 即時提款
    <local_pubkey> OP_CHECKSIGVERIFY
    <remote_pubkey> OP_CHECKSIG
ENDIF
"""

這種腳本的哈希成為 commitment 交易輸出的一部分，進而成為主鏈區塊的一部分。

常見問題解答

Q: 為什麼區塊頭固定為 80 位元組？

區塊頭的固定大小是共識協議設計的結果。80 位元組的大小：

1. 適合網路傳輸和儲存
2. 使得 Merkle 證明緊湊
3. 確保工作量證明計算的高效性
4. 避免礦工填入過多無用數據

Q: 區塊可以包含多少筆交易？

這取決於交易的大小：

• 最小交易: 約 61 位元組
• 最大區塊: 4,000,000 weight units
• 理論最大交易數: ~4,000,000 / 4 ≈ 1,000,000 筆（全是最小交易）
• 實際常見: 2,000-3,000 筆（平均每筆約 250-500 bytes）

Q: 為什麼要計算兩次 SHA-256？

比特幣使用 SHA-256d（即 SHA-256 twice）的原因：

SHA-256d 的優勢:
1. 防止 Length Extension Attack
2. 增加碰撞攻擊難度
3. 避免部分已知的 SHA-256 結構化攻擊
4. 與其他系統（如 HMAC）的設計一致

Q: Merkle 根如何防止交易重排攻擊？

攻擊者無法在不改變 Merkle 根的情況下重新排列交易。Merkle 樹的建構方式是確定的——給定交易集合，只有唯一的 Merkle 根。任何順序或內容的改變都會導致不同的 Merkle 根。

結論

比特幣區塊結構的設計體現了中本聰在密碼學、分佈式系統和經濟學領域的深刻洞察。80 位元組的固定區塊頭承載了共識驗證所需的所有信息；Merkle 樹在保證安全性的同時實現了高效的客戶端驗證；工作量證明機制將經濟激勵與密碼學安全巧妙結合。理解這些技術細節，不僅有助於比特幣系統的安全開發，也為區塊鏈技術的進一步創新奠定了基礎。

隨著 Taproot 等升級的實施，比特幣的區塊結構持續演進，但其核心設計原則——簡單性、安全性和去中心化——始終保持不變。

相關 BIP 提案:

• BIP-141: Segregated Witness (隔離見證)
• BIP-144: Segregated Witness Peer Services
• BIP-145: getblocktemplate Updates for Segregated Witness
• BIP-152: Compact Blocks
• BIP-340: Taproot (Schnorr Signatures)
• BIP-341: Taproot (Commitment Creation)
• BIP-342: Taproot (Script Validation)

相關比特幣源碼:

• src/primitives/block.h: 區塊頭結構定義
• src/consensus/merkle.cpp: Merkle 樹計算
• src/pow.cpp: 工作量證明驗證

延伸閱讀:

• 比特幣白皮書第 3-7 節：區塊結構與驗證
• 《Mastering Bitcoin》第 9 章：比特幣網路
• 《Programming Bitcoin》第 4 章：交易

標籤: 比特幣、區塊結構、區塊頭、Merkle樹、工作量證明、SegWit、Taproot、共識機制、密碼學

難度等級: 專業

預估閱讀時間: 45 分鐘

數學基礎要求: 密碼學基礎、資料結構（Merkle Tree）、位元組操作

發布日期: 2026-03-24

最後更新: 2026-03-24