技术深度解析
Bitcoin Core 是软件工程的一大奇迹，它将安全性与确定性置于性能和功能迭代速度之上。其架构堪称模块化设计的典范，但各组件之间的相互依赖关系使得安全修改系统变得异常困难。
UTXO 模型：网络的状态
Bitcoin Core 的核心是 UTXO（未花费交易输出）数据库。与基于账户的模型（如以太坊）不同，比特币不通过余额追踪所有权，而是通过一组未花费的输出来实现。每笔交易消耗一个或多个 UTXO 作为输入，并创建新的 UTXO 作为输出。这种模型天然更易于并行化且更具隐私保护性，但会导致状态单调增长。截至 2026 年初，UTXO 集包含超过 2 亿个条目，需要大量 RAM 和快速存储（SSD）才能高效运行。使用 LevelDB 实现的 `coins` 数据库是交易验证的关键路径。
共识：工作量证明与难度调整
Bitcoin Core 通过 SHA-256d 工作量证明实现了中本聪共识。难度调整算法每 2016 个区块（约两周）重新计算一次，是负反馈机制的杰作。它确保无论总算力如何，区块都大约每 10 分钟被发现一次。当前网络算力已超过 600 EH/s。用于验证区块头、检查工作量证明以及验证 Merkle 树的代码极其简洁——这证明了原始设计的优雅。`validation.cpp` 中的 `CheckBlock` 和 `AcceptBlock` 函数是历史上被审计次数最多的代码之一。
P2P 网络协议：八卦与中继
P2P 层负责发现对等节点、中继交易和区块，以及初始区块下载（IBD）。Bitcoin Core 使用一种八卦协议，节点向其对等节点广播新交易和区块。`addr` 消息用于发现对等节点，而 `inv`（库存）消息允许节点请求它们缺失的数据。近期一项关键的改进是实现了 Erlay（BIP-330），它通过使用集合协调而非泛洪来减少交易中继的带宽消耗。这是一项重大的工程胜利，使得运行全节点的成本更低。
脚本系统：最初的智能合约
比特币的脚本语言有意设计为非图灵完备，缺少循环。这一设计选择防止了无限循环，并使交易验证变得可预测。该脚本是一种基于栈的语言，主要用于检查签名和时间锁。尽管功能有限，但它支持强大的结构，如多重签名地址、支付通道（闪电网络的基础）以及时间锁定交易。`script/script.h` 和 `script/interpreter.cpp` 文件定义了操作码和执行环境。脚本系统的简单性是一个特性，而非缺陷；它最大限度地减少了攻击面。
关键 GitHub 仓库与工具
* bitcoin/bitcoin：核心客户端。最近的提交专注于改进 `assumevalid` 机制以加速 IBD，并增强 `mempool`（内存池）逻辑以实现更好的费用估算。
* bitcoin/bips：比特币改进提案仓库。社区在此讨论并正式确定协议变更。像 Taproot（BIP-341）和 Schnorr 签名（BIP-340）这样的 BIP 在 Core 中实现之前，都是在这里敲定的。
* lightningnetwork/lnd：最流行的闪电网络实现。虽然不属于 Core 的一部分，但它是 Core 所支持的主要扩容解决方案。
性能基准测试
下表比较了运行 Bitcoin Core 节点与其他主流区块链客户端的资源需求和性能。
| 客户端 | 初始同步时间（SSD） | 内存使用（空闲） | 存储空间（全节点） | 交易吞吐量（TPS） |
|---|---|---|---|---|
| Bitcoin Core 28.x | 2-4 天 | ~2 GB | ~650 GB | ~7（受区块大小限制） |
| Geth（以太坊） | 1-2 天（快照同步） | ~4 GB | ~1.2 TB | ~15-30（受 Gas 限制） |
| Solana 验证节点 | 1-2 小时 | ~128 GB（推荐） | ~2 TB | ~4,000 |
数据要点： Bitcoin Core 在内存使用方面最为高效，但需要大量的前期时间投入进行 IBD。其吞吐量被有意限制以维护去中心化，这是 Solana 和以太坊为了追求更高性能而拒绝的权衡，代价是更高的硬件要求。
关键参与者与案例研究
Bitcoin Core 是一个独特的开源项目，因为它没有任何单一的企业支持者。其开发由分散的公司、基金会和个人捐赠者网络资助。
核心维护者
该项目目前由一小群维护者指导，包括 Wladimir J. van der Laan（他于 2024 年卸任，但仍具影响力）、Pieter Wuille