比特幣核心客戶端共識層原始碼深度解析：從密碼學原語到共識規則

摘要

比特幣核心（Bitcoin Core）是比特幣網路最廣泛使用的客戶端實現，其原始碼涵蓋了從密碼學原語到網路協議、再到共識機制的完整技術棧。本文從原始碼層級深入分析比特幣核心客戶端的共識層實現，涵蓋交易驗證引擎、區塊驗證邏輯、腳本解釋器（Script Interpreter）、共識規則的代碼組織結構、以及近期軟分叉升級的實作方式。本文旨在為開發者提供比特幣共識層的系統性原始碼閱讀指南，並揭示比特幣設計決策背後的工程考量。

第一章：比特幣核心原始碼組織結構

1.1 原始碼倉庫概覽

比特幣核心的原始碼托管於 GitHub（bitcoin/bitcoin），採用 MIT 開源許可證。截至 2026 年，倉庫包含超過 600,000 行代碼（C++ 為主），涵蓋共識引擎、錢包、網路層、RPC 接口等模組。

原始碼目錄結構：

bitcoin/
├── src/                    # 主要源代碼目錄
│   ├── consensus/           # 共識規則（核心）
│   ├── validation.cpp      # 區塊驗證邏輯
│   ├── txverify.cpp        # 交易驗證
│   ├── script/             # 腳本引擎
│   ├── pow.cpp             # 工作量證明驗證
│   ├── amount.cpp          # 金額與貨幣單位
│   ├── coins.cpp           # UTXO 集合管理
│   ├── net_processing.cpp  # 網路消息處理
│   ├── net.cpp             # 網路底層
│   ├── validation.h        # 驗證介面
│   └── ...
├── test/                   # 單元測試
├── contrib/                # 工具腳本
└── configure.ac            # 構建配置

共識層的獨立性設計：

比特幣核心的一個重要設計原則是將共識規則與網路/錢包功能分離。src/consensus/ 目錄下的代碼代表不可篡改的共識邏輯，原則上不應該依賴於網路或錢包代碼。

這種設計的優點：

• 共識規則邏輯清晰，易於審計
• 便於其他客戶端（如 btcd、Libbitcoin）重用共識代碼
• 降低了共識規則被意外修改的風險

1.2 關鍵類與數據結構

CTransaction 和 CCoins：

比特幣核心使用 C++ 類封裝交易和 UTXO 數據結構：

// src/primitives/transaction.h
class CTransaction {
public:
    static const int32_t CURRENT_VERSION = 2;
    const int32_t nVersion;
    const std::vector<CTxIn> vin;
    const std::vector<CTxOut> vout;
    const uint32_t nLockTime;
    
    // 交易 ID（不包含見證數據）
    uint256 GetHash() const;
    
    // 見證 ID（包含見證數據，用於 SegWit）
    uint256 GetWitnessHash() const;
};

CTransaction 是不可變的（immutable），這簡化了並發處理邏輯。交易的哈希計算使用 SHA-256 雙重哈希：

// src/hash.h
uint256 GetHash(const CTransaction& tx) {
    return Hash(tx.nVersion, tx.vin, tx.vout, tx.nLockTime);
}

uint256 GetWitnessHash(const CTransaction& tx) {
    return SerializeHash(tx, SER_GETHASH | SER_WITNESS_SECRET);
}

CTxIn 和 CTxOut：

// 交易輸入：引用先前交易的輸出
class CTxIn {
public:
    COutPoint prevout;       // 前一筆交易的輸出索引
    CScript scriptSig;        // 解鎖腳本（簽名前）
    uint32_t nSequence;       // 序列號（用於 RBF/CSV）
};

// 交易輸出：可花費的比特幣金額
class CTxOut {
public:
    CAmount nValue;           // 金額（以 satoshi 為單位）
    CScript scriptPubKey;     // 鎖定腳本
};

1.3 金額表示與算術運算

比特幣使用 CAmount 類型表示金額，以 satoshi（聰）為基本單位：

// src/amount.h
typedef int64_t CAmount;
static constexpr CAmount COIN = 100000000;      // 1 BTC = 10^8 satoshi
static constexpr CAmount CENT = 1000000;         // 0.01 BTC
static constexpr CAmount MAX_MONEY = 21000000 * COIN;  // 2100 萬 BTC

MAX_MONEY 常量定義了比特幣的最大貨幣量，這是一個共識級別的約束：

// src/validation.cpp
static constexpr Amount MAX_MONEY = 21000000 * COIN;

bool MoneyRange(const CAmount& nValue) {
    return nValue >= 0 && nValue <= MAX_MONEY;
}

第二章：腳本語言 Script 引擎

2.1 腳本系統概述

比特幣使用名為「Script」的堆疊式腳本語言定義交易解鎖條件。比特幣腳本引擎位於 src/script/ 目錄，是比特幣共識層的核心組件之一。

腳本的基本設計原則：

比特幣腳本語言刻意設計為：

• 非圖靈完全：排除迴圈結構，防止無限執行攻擊
• 基於堆疊：所有操作都是對堆疊的 push/pop 操作
• 確定性：腳本執行結果在所有節點上完全一致

// src/script/interpreter.h
enum opcodetype : uint8_t
{
    OP_0 = 0x00,
    OP_FALSE = OP_0,
    OP_PUSHDATA1 = 0x4c,
    OP_PUSHDATA2 = 0x4d,
    OP_PUSHDATA4 = 0x4e,
    OP_1NEGATE = 0x4f,
    OP_RESERVED = 0x50,
    // ... 更多操作碼
    OP_CHECKSIG = 0xac,
    OP_CHECKMULTISIG = 0xae,
    // ... 更多操作碼
};

2.2 常見腳本模板

比特幣支持多種腳本模板，最常見的包括：

P2PKH（Pay to Public Key Hash）：

這是比特幣早期最廣泛使用的地址格式。P2PKH 的腳本結構：

锁定脚本 (ScriptPubKey): OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
解锁脚本 (ScriptSig): <Signature> <PublicKey>

比特幣核心的 P2PKH 驗證邏輯：

// src/script/standard.cpp
bool IsPayToPublicKeyHash(const CScript& script)
{
    // P2PKH 格式：OP_DUP OP_HASH160 <20 bytes> OP_EQUALVERIFY OP_CHECKSIG
    if (script.size() == 25 && script[0] == OP_DUP && 
        script[1] == OP_HASH160 && script[2] == 20 &&
        script[23] == OP_EQUALVERIFY && script[24] == OP_CHECKSIG)
    {
        return true;
    }
    return false;
}

P2SH（Pay to Script Hash）：

P2SH 允許支付到任意腳本的哈希值，使得複雜腳本的使用成本由接收方承擔：

锁定脚本: OP_HASH160 <ScriptHash> OP_EQUAL
解锁脚本: <原脚本> <见证数据（如果使用P2WSH）>

P2WPKH（Pay to Witness Public Key Hash）：

這是 SegWit v0 引入的地址格式，將見證數據移到交易結構的單獨區域：

锁定脚本: OP_0 <20-byte-pubkey-hash>
见证数据: <signature> <pubkey>

2.3 腳本解釋器核心邏輯

比特幣核心的腳本解釋器位於 src/script/interpreter.cpp，是共識層最複雜的組件之一。

解釋器的主要函數：

// src/script/interpreter.cpp
class CScriptExecutionContext {
    const CScript& script;
    CScript::const_iterator pbegincodehash;
    opcodetype opcode;
    valtype vchPushValue;
    
    // ... 用於追蹤執行狀態
};

static bool EvalScript(const CScript& script, 
                       CScriptExecutionContext& context,
                       unsigned int flags,
                       const BaseSignatureChecker& checker,
                       ScriptExecutionMetrics& metrics) {
    // 主腳本執行循環
    while (!context.end()) {
        // 讀取下一個操作碼
        context.getOp(context.opcode, context.vchPushValue);
        
        // 根據操作碼類型分發處理
        switch (context.opcode) {
            case OP_CHECKSIG:
                return context.checkSig(checker);
            case OP_CHECKMULTISIG:
                return context.checkMultiSig(checker);
            // ... 其他操作碼
        }
    }
    return true;
}

簽名驗證（OP_CHECKSIG）：

OP_CHECKSIG 是比特幣腳本中最重要的操作碼之一，負責驗證 ECDSA 簽名：

// src/script/interpreter.cpp (簡化版本)
bool CScriptExecutionContext::checkSig(const BaseSignatureChecker& checker) {
    // 從堆疊彈出簽名和公鑰
    valtype vchSig, vchPubKey;
    if (!pop(vchSig) || !pop(vchPubKey))
        return false;
    
    // 移除簽名中的哈希類型後綴
    uint32_t nHashType = vchSig.back();
    vchSig.pop_back();
    
    // 獲取交易副本並處理 SIGHASH
    CTransaction txToCopy = txTo;
    PrecomputedTransactionData txdata;
    if (nHashType & SIGHASH_ANYONECANPAY) {
        // SIGHASH_ANYONECANPAY: 只簽名當前輸入
        // ... 調整交易輸入
    }
    
    // 驗證簽名
    uint256 sighash = SignatureHash(script, txToCopy, 
                                     nIn, nHashType, 
                                     prevouts.nAmount, 
                                     txdata, flags);
    
    return checker.CheckSig(vchSig, vchPubKey, sighash, script);
}

2.4 SIGHASH 標誌與交易簽名

SIGHASH 標誌決定了簽名覆蓋交易的哪些部分，這是比特幣腳本靈活性的關鍵。

SIGHASH 類型定義：

// src/script/sign.h
enum : uint32_t {
    SIGHASH_ALL = 0x01,        // 簽名覆蓋所有輸入和輸出
    SIGHASH_NONE = 0x02,       // 簽名覆蓋所有輸入，不包含任何輸出
    SIGHASH_SINGLE = 0x03,     // 簽名覆蓋所有輸入，但只包含與此輸入對應的輸出
    SIGHASH_ANYONECANPAY = 0x80,  // OR 運算：只簽名當前輸入
};

簽名哈希計算：

// src/script/interpreter.cpp
uint256 SignatureHash(const CScript& scriptCode,
                     const CTransaction& txTo,
                     unsigned int nIn,
                     uint32_t nHashType,
                     const CAmount& amount,
                     SigVersion sigversion,
                     const PrecomputedTransactionData* cache) {
    // 基於 SIGHASH 類型構建不同的簽名哈希
    switch (nHashType & 0x1f) {
        case SIGHASH_ALL:
            return SignatureHashAllInputs(scriptCode, txTo, nIn, 
                                          amount, sigversion, cache);
        case SIGHASH_NONE:
            return SignatureHashNoInputs(scriptCode, txTo, nIn,
                                         amount, sigversion, cache);
        case SIGHASH_SINGLE:
            return SignatureHashSingleInput(scriptCode, txTo, nIn,
                                           amount, sigversion, cache);
    }
}

2.5 Taproot 腳本升級（BIP-340/341/342）

2021 年 11 月激活的 Taproot 升級引入了全新的腳本功能，包括 Schnorr 簽名和 MAST 結構。

BIP-340 Schnorr 簽名：

Taproot 使用 BIP-340 定義的 Schnorr 簽名方案。與 ECDSA 不同，Schnorr 簽名具有線性可聚合性：

// src/script/interpreter.cpp (Taproot 實現)
static bool VerifySchnorrSignature(const valtype& sig,
                                    const valtype& pubkey,
                                    const uint256& sighash,
                                    SigVersion sigversion,
                                    const ScriptExecutionContext& context,
                                    unsigned int flags) {
    // BIP-340 格式：64 字節簽名 (R, s) + 可選的 hashtype 後綴
    if (sig.size() != 64 && sig.size() != 65)
        return false;
    
    // 驗證 Schnorr 簽名
    // s * G = R + H(R || P || m) * P
    return context.check Schnorr(sig, pubkey, sighash);
}

BIP-341 MAST（Merkle Abstract Syntax Tree）：

Taproot 引入 MAST 結構，允許將多個潛在腳本封裝在一棵 Merkle 樹中：

// src/script/taproot.cpp (概念性代碼)
class TaprootMerkleRoot {
public:
    // 計算 MAST 根哈希
    static uint256 ComputeMerkleRoot(
        const std::vector<std::vector<uint8_t>>& script_tree) {
        // 構建 Merkle 樹並返回根哈希
        std::vector<uint256> leaves;
        for (const auto& script : script_tree) {
            leaves.push_back(Hash(script));
        }
        return BuildMerkleTree(leaves);
    }
    
    // 驗證腳本路徑
    static bool VerifyScriptPath(
        const std::vector<uint256>& merkle_branch,
        int leaf_version,
        const std::vector<uint8_t>& script,
        const uint256& expected_root) {
        uint256 hash = HashTapLeaf(script, leaf_version);
        for (const auto& branch : merkle_branch) {
            hash = HashTapBranch(hash, branch);
        }
        return hash == expected_root;
    }
};

第三章：交易驗證引擎

3.1 CheckTransaction 函數

交易驗證的第一步是確保交易結構的有效性。CheckTransaction 函數定義了所有比特幣節點都必須執行的基本檢查：

// src/validation.cpp
static bool CheckTransaction(const CTransaction& tx, 
                            TxValidationState& state,
                            bool fCheckDuplicateInputs,
                            bool check_p2sh_20bytes) {
    // 1. 基本結構檢查
    if (tx.vin.empty() || tx.vout.empty()) {
        return state.Invalid(TxValidationResult::TX_CONSENSUS, 
                            "bad-txns-vin-empty");
    }
    
    // 2. 金額溢出檢查
    CAmount nValueOut = 0;
    for (const auto& txout : tx.vout) {
        if (!MoneyRange(txout.nValue)) {
            return state.Invalid(TxValidationResult::TX_CONSENSUS,
                                "bad-txns-vout-toolarge");
        }
        nValueOut += txout.nValue;
        if (!MoneyRange(nValueOut)) {
            return state.Invalid(TxValidationResult::TX_CONSENSUS,
                                "bad-txns-vout-overflow");
        }
    }
    
    // 3. 金額守恆檢查
    // 輸入總金額不應超過輸出總金額
    CAmount nValueIn = GetValueIn(tx);
    if (nValueIn < nValueOut) {
        return state.Invalid(TxValidationResult::TX_CONSENSUS,
                            "bad-txns-in-belowout");
    }
    
    // 4. 輸入不重複檢查
    if (fCheckDuplicateInputs) {
        std::set<COutPoint> vInOutPoints;
        for (const auto& txin : tx.vin) {
            if (vInOutPoints.count(txin.prevout)) {
                return state.Invalid(TxValidationResult::TX_CONSENSUS,
                                    "bad-txns-inputs-duplicate");
            }
            vInOutPoints.insert(txin.prevout);
        }
    }
    
    // 5. 序列號範圍檢查
    for (const auto& txin : tx.vin) {
        if (txin.nSequence > CTxIn::SEQUENCE_FINAL) {
            // 如果 nSequence < SEQUENCE_FINAL，則交易是可選替換的
            // 這裡需要驗證序列號的使用是否合法
        }
    }
    
    return true;
}

3.2 Coinbase 交易驗證

區塊的第一筆交易（coinbase 交易）有特殊的驗證規則：

// src/validation.cpp
static bool CheckCoinbase(const CTransaction& tx, TxValidationState& state,
                         int height) {
    // Coinbase 交易不應該有輸入（或輸入引用區塊高度）
    if (!tx.vin.empty() && !IsCoinbaseHeightInput(tx.vin[0])) {
        // BIP-34: Coinbase 必須包含區塊高度
        // BIP-34 之前的舊規則：vin[0].prevout 應為空
    }
    
    // Coinbase 不應該有序列號限制
    for (const auto& vin : tx.vin) {
        if (vin.nSequence != CTxIn::SEQUENCE_FINAL) {
            return state.Invalid(TxValidationResult::TX_CONSENSUS,
                                "bad-cb-sequence");
        }
    }
    
    // Coinbase 的輸出金額檢查
    // 必須等於 block_reward + fees
    CAmount nExpectedReward = GetBlockSubsidy(height, chainparams.GetConsensus());
    CAmount nFees = GetFeesInBlock(tx);
    if (tx.GetValueOut() > nExpectedReward + nFees) {
        return state.Invalid(TxValidationResult::TX_CONSENSUS,
                            "bad-cb-amount");
    }
    
    return true;
}

3.3 區塊獎勵與手續費計算

比特幣核心定義了精確的區塊獎勵計算邏輯：

// src/consensus/amount.h
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& params) {
    int nSubsidyHalvings = nHeight / params.nSubsidyHalvingInterval;
    
    // 區塊獎勵不能為負
    if (nSubsidyHalvings >= 64)
        return 0;
    
    CAmount nSubsidy = 50 * COIN;  // 初始獎勵：50 BTC
    // 每 210,000 區塊減半一次
    nSubsidy >>= nSubsidyHalvings;
    
    return nSubsidy;
}

這個函數的實現揭示了比特幣貨幣政策的精確性：

• 初始區塊獎勵為 50 BTC（50 × 10^8 satoshi）
• 每 210,000 個區塊（nSubsidyHalvingInterval）減半一次
• 64 次減半後獎勵為 0（因為使用位移運算）
• 總供應量 = 50 × 210,000 × (1 + 1/2 + 1/4 + ...) = 21,000,000 BTC

第四章：區塊驗證邏輯

4.1 ContextualCheckBlock 函數

ContextualCheckBlock 函數驗證區塊的共識相關屬性，包括時間戳、難度和 Coinbase 數據：

// src/validation.cpp
static bool ContextualCheckBlock(const CBlock& block, 
                                  BlockValidationState& state,
                                  const CChainParams& chainparams,
                                  const CBlockIndex* pindexPrev) {
    const int nHeight = pindexPrev->nHeight + 1;
    
    // 1. 區塊時間戳檢查
    // 區塊時間必須晚於上一區塊的 Median Time Past
    if (block.GetBlockTime() <= pindexPrev->GetMedianTimePast()) {
        return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER,
                           "time-too-old");
    }
    
    // 區塊時間不能太遠未來（最多 2 小時）
    if (block.GetBlockTime() > nMedianTime + 2 * 60 * 60) {
        return state.Invalid(BlockValidationResult::BLOCK_TOO_MUCH_FUTURE,
                           "time-too-future");
    }
    
    // 2. Coinbase 區塊高度檢查（BIP-34）
    if (VersionBitsState(pindexPrev, chainparams.GetConsensus(), 
                         Consensus::DEPLOYMENT_HEIGHTINCB, 
                         versionbitscache) == ThresholdState::ACTIVE) {
        CScript expect = CScript() << nHeight;
        if (!std::equal(expect.begin(), expect.end(), 
                       block.vtx[0]->vin[0].scriptSig.begin())) {
            return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS,
                               "bad-cb-height");
        }
    }
    
    // 3. Coinbase 見證根檢查（BIP-34 升級：使用 commit）
    // ... BIP-34, BIP-65, BIP-66 相關檢查
    
    // 4. Witness commitment 檢查（BIP-141）
    if (VersionBitsState(pindexPrev, chainparams.GetConsensus(),
                         Consensus::DEPLOYMENT_SEGWIT,
                         versionbitscache) == ThresholdState::ACTIVE) {
        // 驗證 witness commitment 存在於 coinbase 輸出中
        checkWitnessCommitment(block.vtx[0], block.GetWitnessRoot());
    }
    
    return true;
}

4.2 CheckBlock 函數

CheckBlock 函數驗證區塊的物理結構和交易格式：

// src/validation.cpp
static bool CheckBlock(const CBlock& block, 
                       BlockValidationState& state,
                       const CChainParams& chainparams,
                       bool fCheckPOW,
                       bool fCheckMerkleRoot) {
    // 1. 基本結構檢查
    if (block.vtx.empty() || block.vtx.size() > MaxBlockSize())
        return false;
    
    // 2. 區塊大小檢查
    if (::GetSerializeSize(block, PROTOCOL_VERSION) > MaxBlockSize())
        return state.Invalid(BlockValidationResult::BLOCK_BAD_AND_DISK,
                           "bad-blk-length");
    
    // 3. Coinbase 交易檢查
    if (!IsCoinBase(block.vtx[0]))
        return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS,
                           "bad-cb-missing");
    
    // 4. 工作量證明檢查（可選）
    if (fCheckPOW) {
        // 驗證區塊頭的哈希值低於目標難度
        if (!CheckProofOfWork(block.GetHash(), block.nBits, chainparams.GetConsensus()))
            return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER,
                               "high-hash");
    }
    
    // 5. Merkle 根檢查
    if (fCheckMerkleRoot) {
        uint256 hashMerkleRoot = block.BuildMerkleTree();
        if (block.hashMerkleRoot != hashMerkleRoot)
            return state.Invalid(BlockValidationResult::BLOCK_MUTATED,
                               "bad-txnmrklroot");
    }
    
    // 6. 見證 Merkle 根檢查（SegWit）
    if (block.GetWitnessMerkleRoot() != block.hashWitnessMerkleRoot)
        return state.Invalid(BlockValidationResult::BLOCK_MUTATED,
                           "bad-witness-merkle-root");
    
    return true;
}

4.3 工作量證明驗證

工作量證明是比特幣共識的核心，CheckProofOfWork 函數驗證區塊頭的哈希值是否滿足難度要求：

// src/pow.cpp
bool CheckProofOfWork(uint256 hash, unsigned int nBits, 
                      const Consensus::Params& params) {
    // 1. 計算目標值
    uint256 bnTarget;
    if (!UintToArith256(nBits, bnTarget))
        return false;
    
    // 目標值必須為正且不能太大
    if (bnTarget == 0 || bnTarget > params.powLimit)
        return false;
    
    // 2. 驗證哈希值小於目標值
    uint256 hash_arith = UintToArith256(hash);
    if (hash_arith > bnTarget)
        return false;
    
    return true;
}

// 目標值計算（nBits 反向解析）
bool GetBlockProofEquivalentTime(const CBlockIndex& pblockA,
                                 const CBlockIndex& pblockB,
                                 const CBlockIndex& pindexC,
                                 const Consensus::Params& params) {
    // 計算找到 pblockA 和 pblockB 所需的預期時間
    // 用於驗證時間戳的合理性
}

4.4 難度調整算法（DAA）

2017 年改進的難度調整算法（DAA）取代了原有的緊急難度調整（EDA），提供了更平滑的難度調整：

// src/pow.cpp
unsigned int GetNextCashWorkRequired(const CBlockIndex* pindexLast,
                                     const CBlockHeader* pblock,
                                     const Consensus::Params& params) {
    // DAA 實現：使用加權中位數時間
    // 目標是每 10 分鐘出一個區塊
    
    // 歷史數據窗口：最後 144 個區塊（~24 小時）
    // 計算算力變化的加權平均值
    
    // 限制每次調整幅度：最大 ±20%
    // 防止算力急劇變化時難度調整過度
    
    return newTarget;
}

第五章：UTXO 集合管理

5.1 CCoins 視圖模型

比特幣核心使用 CCoinsView 抽象介面管理 UTXO 集合，支持多層級的視圖緩存：

// src/coins.h
class CCoinsView {
public:
    // 查詢 UTXO
    virtual bool GetCoin(const COutPoint& outpoint, Coin& coin) const = 0;
    
    // 遍歷 UTXO
    virtual bool HaveCoin(const COutPoint& outpoint) const = 0;
    
    // 獲取 UTXO 總金額
    virtual CAmount GetCoinSupply() const = 0;
    
    // 批次查詢（優化）
    virtual std::vector<std::pair<COutPoint, Coin>> GetCoins(
        const std::vector<COutPoint>& outpoints) const;
};

視圖層級結構：

CCoinsViewDB (LevelDB)          ← 持久化存儲
        ↑
CCoinsViewCache (CoinsCache)    ← 內存緩存
        ↑
CCoinsViewMemPool              ← 記憶池中的 UTXO

5.2 交易輸入驗證

// src/validation.cpp
static bool CheckTxInputs(const CTransaction& tx, TxValidationState& state,
                         const CCoinsViewCache& inputs, 
                         const CCoinsView& coinview,
                         int nSpendHeight) {
    // 遍歷所有輸入
    for (unsigned int i = 0; i < tx.vin.size(); i++) {
        const COutPoint& prevout = tx.vin[i].prevout;
        
        // 1. 檢查 UTXO 是否存在
        const Coin& coin = inputs.AccessCoin(prevout);
        if (!coin.IsSpent()) {
            return state.Invalid(TxValidationResult::TX_PREMATURE_SPEND,
                               "bad-txns-inputs-missingorspent");
        }
        
        // 2. 驗證金額
        if (tx.vin[i].GetValueIn() != coin.out.nValue) {
            return state.Invalid(TxValidationResult::TX_CONSENSUS,
                               "bad-txns-inputvalues");
        }
        
        // 3. 檢查腳本是否匹配
        // ... script 驗證
    }
    
    // 4. 計算並驗證手續費
    CAmount nTxFee = GetValueIn(tx) - GetValueOut(tx);
    if (nTxFee < 0) {
        return state.Invalid(TxValidationResult::TX_CONSENSUS,
                           "bad-txns-in-belowout");
    }
    
    return true;
}

5.3 自私挖礦防禦機制

比特幣核心包含了對自私挖礦（Selfish Mining）的部分防禦機制：

// 概念性說明（比特幣核心不直接實現自私挖礦檢測）
// 自私挖礦的關鍵在於：攻擊者隱藏私有區塊鏈，在公有鏈落後時釋放

// 防禦機制：
// 1. 區塊獎勵延遲釋放（Coinbase Maturity）
//    交易確認後需要 100 個區塊才能花費
//    這降低了自私挖礦的即時收益

// 2. 孤塊率監控
//    節點可以監控孤塊率，間接檢測異常

// 3. 礦池參數限制
//    F2Pool、AntPool 等大型礦池的算力份額
//    目前最大礦池份額不超過 20%

第六章：軟分叉機制與升級策略

6.1 版本位（Version Bits）機制

比特幣使用版本位（Version Bits）機制實現軟分叉升級，這允許網路在不需要硬分叉的情況下引入新規則：

// src/consensus/params.h
struct Consensus::Params {
    // BIP-9 版本位參數
    struct BIP9Deployment {
        int bit;                    // 版本字段中的位位置
        int64_t nStartTime;         // 部署開始時間
        int64_t nTimeout;           // 部署超時時間
        int64_t nMinLockedChainwork; // 最小鎖定算力
        int64_t nWindowSize;        // 統計窗口大小
        int64_t nThreshold;         // 閾值
    };
    
    std::map<std::string, BIP9Deployment> vDeployments;
};

閾值激活機制：

// src/validation.cpp
ThresholdState VersionBitsTipState(const Consensus::Params& params, 
                                  int bit) {
    // 在一個統計窗口（通常是 2016 個區塊）內
    // 統計支持該升級的區塊比例
    // 如果超過閾值（通常是 95%），則激活
    
    // 計算過去 nWindowSize 個區塊中
    // 版本字段包含指定 bit 的區塊數量
    int count = 0;
    for (const CBlockIndex* pindex : vSortedBlockHeaderByHeight) {
        if (pindex->nVersion & (1 << bit))
            count++;
    }
    
    return (count >= nThreshold) ? ACTIVE : LOCKED_IN;
}

6.2 軟分叉歷史案例

BIP-34（區塊高度 Coinbase）：

// BIP-34: Coinbase 輸入必須包含區塊高度
// 激活時間：2013 年 3 月（區塊高度 227,836）

// 實現方式：
// 1. 礦工開始在 Coinbase 中添加區塊高度
// 2. 當 95% 的區塊包含高度時，規則激活
// 3. 之後的區塊如果 Coinbase 缺少高度，則被拒絕

BIP-141（SegWit）：

// BIP-141: 隔離見證
// 激活時間：2017 年 8 月（區塊高度 481,824）

// 關鍵變更：
// 1. 區塊結構新增 witness 字段
// 2. 交易費用計算包含 witness 數據
// 3. 新的腳本類型：P2WPKH, P2WSH
// 4. Witness commitment 包含在 coinbase 輸出中

BIP-340/341/342（Taproot）：

// Taproot 升級：2021 年 11 月（區塊高度 709,632）

// 關鍵變更：
// 1. BIP-340: Schnorr 簽名
// 2. BIP-341: Taproot（Merkle 樹結構）
// 3. BIP-342: Tapscript（升級的腳本語言）

6.3 軟分叉的向后兼容性

軟分叉的一個核心特性是向后兼容性：運行新版本節點的礦工可以驗證新類型的區塊，而舊版本節點可以接受這些區塊（即使不完全理解）：

         ┌─────────────────────────────────────────┐
         │          軟分叉的向后兼容性              │
         ├─────────────────────────────────────────┤
         │                                         │
         │  舊節點：                                │
         │  - 只驗證「基本」共識規則                  │
         │  - 接受新類型的區塊（因為它們滿足基本規則）  │
         │                                         │
         │  新節點：                                │
         │  - 驗證基本規則 + 新規則                   │
         │  - 生產符合新舊規則的區塊                  │
         │                                         │
         │  結果：                                  │
         │  - 新舊節點可以共存                       │
         │  - 升級是漸進的、自願的                   │
         │  - 避免了硬分叉的風險                     │
         │                                         │
         └─────────────────────────────────────────┘

第七章：比特幣核心 vs 其他客戶端實現

7.1 主要比特幣客戶端實現

比特幣網路中存在多個獨立的客戶端實現，這是健康生態系統的重要標誌：

7.2 客戶端多樣性的重要性

比特幣核心客戶端多樣性是網路安全的重要因素：

避免單點故障：

如果所有節點都運行相同的客戶端代碼，任何軟體漏洞都會導致整個網路的災難性故障。客戶端多樣性提供了「防火牆」。

防止開發者俘獲：

比特幣網路的價值取決於其去中心化特性。如果比特幣核心開發團隊被某個利益集團控制，網路可能走向不利於用戶的方向。多個獨立的客戶端實現防止了這種「開發者俘獲」。

加速創新：

不同的客戶端實現可以嘗試不同的技術方向，失敗的實驗不會影響整個網路。

7.3 共識層一致性測試

比特幣核心使用廣泛的測試套件確保共識規則的一致性：

// src/test/validation_tests.cpp

// 1. 區塊獎勵測試
BOOST_AUTO_TEST_CASE(block_subsidy_test) {
    // 驗證每 210,000 區塊獎勵正確減半
    CAmount subsidy = GetBlockSubsidy(0, params);
    BOOST_CHECK_EQUAL(subsidy, 50 * COIN);
    
    subsidy = GetBlockSubsidy(210000, params);
    BOOST_CHECK_EQUAL(subsidy, 25 * COIN);
    
    // ... 更多測試用例
}

// 2. Coinbase 成熟度測試
BOOST_AUTO_TEST_CASE(coinbase maturity test) {
    // Coinbase 輸出需要 100 個區塊確認後才能花費
    // 測試不同成熟度下的花費行為
}

// 3. SIGHASH 類型測試
BOOST_AUTO_TEST_CASE(sighash test) {
    // 驗證不同 SIGHASH 類型的簽名哈希計算
}

第八章：開發者資源與進一步閱讀

8.1 原始碼閱讀建議

推薦的閱讀順序：

1. 數據結構定義（src/primitives/）

• 理解交易、區塊的基本結構

1. 腳本引擎（src/script/）

• 理解比特幣腳本的執行邏輯

1. 共識規則（src/consensus/）

• 理解不可變的共識邏輯

1. 驗證邏輯（src/validation.cpp）

• 理解完整的區塊驗證流程

8.2 關鍵 BIP 規範

以下是理解比特幣共識層最重要的 BIP 規範：

8.3 測試網絡和模擬工具

測試網絡（Testnet）：

比特幣測試網絡允許開發者在無風險環境中測試新功能：

testnet 節點地址：
- DNS 播種節點：testnet-seed.bitcoin.jonasschnelli.ch
- RPC 端口：18332（主網：8332）
- P2P 端口：18333（主網：8333）

Regtest 模式：

本地回歸測試網絡，適合開發和調試：

# 啟動 regtest 節點
bitcoind -regtest -daemon

# 挖出初始區塊
bitcoin-cli -regtest generatetoaddress 101 <address>

# 測試交易
bitcoin-cli -regtest sendtoaddress <address> 10

結論：比特幣核心的工程哲學

比特幣核心客戶端的設計體現了一種獨特的工程哲學：保守主義與創新的平衡。

保守主義的體現：

• 軟分叉優先於硬分叉，確保向后兼容性
• 廣泛的測試覆蓋，防止引入錯誤
• 漸進式升級，降低風險
• 共識規則的不可變性，建立信任

創新的體現：

• Taproot 升級引入全新的密碼學原語
• 持續優化驗證效率（如 libsecp256k1）
• 支持新的腳本功能（如 OP_CHECKTEMPLATEVERIFY）

比特幣核心的代碼是比特幣生態系統的心臟。它將比特幣的哲學願景轉化為可運作的技術系統，是所有其他比特幣相關項目和服務的基石。

理解比特幣核心的原始碼，不僅是技術學習的過程，也是理解比特幣設計哲學的最佳途徑。每一行代碼都承載著多年的安全審計、社群辯論和工程權衡。閱讀這些代碼，就是閱讀比特幣的發明史。

參考文獻

1. Bitcoin Core Source Code. https://github.com/bitcoin/bitcoin
2. BIP-13: P2SH Address Format. https://github.com/bitcoin/bips
3. BIP-16: Pay to Script Hash. https://github.com/bitcoin/bips
4. BIP-34: Block v2, Height in Coinbase. https://github.com/bitcoin/bips
5. BIP-141: Segregated Witness. https://github.com/bitcoin/bips
6. BIP-340: Schnorr Signatures for secp256k1. https://github.com/bitcoin/bips
7. BIP-341: Taproot. https://github.com/bitcoin/bips
8. BIP-342: Tapscript. https://github.com/bitcoin/bips
9. Narayanan, A., et al. (2016). Bitcoin and Cryptocurrency Technologies. Princeton University Press.
10. Antonopoulos, A. M. (2017). Mastering Bitcoin: Programming the Open Blockchain. O'Reilly Media.

文章標籤：比特幣、Bitcoin Core、共識機制、原始碼分析、Script、解釋器、軟分叉、Taproot、SegWit、驗證邏輯

修訂日期：2026-03-25

許可協議：CC BY-SA 4.0