一个 bitcoind 里装着好几个库：Bitcoin Core 的库分层地图

想把比特币核心做二次开发的读者都有同一个困惑：这么大的项目到底从哪读起。其实仓库里自带一张地图——doc/design/libraries.md 把整个项目拆成一组命名规整的库，并画出了它们的依赖箭头。读懂这张图，比从头翻文件快得多。

一张表先认识全员

按该文档的表格逐个过。libbitcoin_cli 是 bitcoin-cli 用的 RPC 客户端功能；libbitcoin_common 与 libbitcoin_util 都是”共享功能的存放处”，区别是前者偏高层、后者偏底层；libbitcoin_consensus 装着共识功能，被节点库和钱包库共同使用；libbitcoin_crypto 专门负责数据加密、哈希、消息认证与密钥派生的硬件优化函数；libbitcoin_kernel 是共识引擎加支撑库，验证工作由它完成；libbitcoinqt 支撑 bitcoin-qt 与 bitcoin-gui 的图形界面；libbitcoin_ipc 在多进程模式下让 bitcoin-node 与 bitcoin-gui 通信；libbitcoin_node 提供 P2P 与 RPC 服务器功能，也就是 bitcoind 的外壳；libbitcoin_wallet 是钱包功能，同时被 bitcoind 和 bitcoin-wallet 命令行工具使用；libbitcoin_wallet_tool 是给 bitcoin-wallet 用的低层钱包工具；libbitcoin_zmq 则是 ZeroMQ 事件推送。

值得注意的读者直觉纠正是：bitcoind 不是”一个可执行文件里塞了一切”，而是节点库、钱包库、共识内核等一层层库的链接产物。同一批库还能拼出别的可执行文件——bitcoin-node、bitcoin-gui 这些拆分进程用的正是同一堆乐高块。

依赖箭头与”内核”的含义

文档要求每个库尽量少依赖别的库，并给了一张依赖方向图。方向大致是：node 依赖 kernel、wallet、net 相关设施；wallet 与 node 都依赖 consensus 与 crypto；cli 只依赖 common/util 级别的东西。这个方向保证了反直觉但重要的一件事——共识规则（libbitcoin_consensus、libbitcoin_kernel）位于依赖图的下方，它们不知道 P2P、RPC、钱包的存在。换句话说，“这个区块是否有效”的判断逻辑，被物理隔离在不会网络 I/O 的代码里。

文档还有一条纪律值得引用：大多数库是内部库，接口完全不稳定、无向后兼容承诺；唯一的例外写明是 libbitcoin_kernel——文档说它”在将来的某个时点会拥有文档化的外部接口”。这解释了为什么第三方项目（做轻验证、做替代节点实现的人）盯着 kernel 的抽取工作，而不是直接链接整条 bitcoind。

代码目录与命名的一一对应

文档给的约定是”一个库对应一个源码目录和一个命名空间”，并举例：libbitcoin_node 的代码在 src/node/、用 node:: 命名空间；wallet 在 src/wallet/、wallet::；ipc 在 src/ipc/、ipc::；util 在 src/util/、util::。它也承认这是进行中的状态：部分命名空间用得并不一致，src/CMakeLists.txt 里的库定义也会从目录外拉文件。对读代码的人，这条约定的实际用法是反向定位：在调试器或调用栈里看到 node::、kernel:: 前缀，就知道自己站在哪座楼里。

与其他文档的关系

想验证某次构建到底编出了哪些库，看构建摘要输出与 src/CMakeLists.txt 的 add_library(bitcoin_* ...) 列表即可；多进程架构动机在隔壁 doc/design/multiprocess.md。库地图回答的问题是”功能住在哪”，它不回答”数据在磁盘上怎么放”（那是 doc/files.md）也不回答”进程间怎么接线”（那是 multiprocess 文档）。三张地图各自独立，读源码时轮流用。

从这张图能推出的三个工程判断

第一，为什么”不碰钱”的部署能做到干净：钱包是独立的库，构建期有 option(ENABLE_WALLET "Enable wallet." ON) 这样的总开关可以整块不编，运行期也可以用 -disablewallet 或空钱包清单让它一个都不装载——分层让”去掉钱包”成为配置或构建选项，而不是散落在主流程里的补丁。第二，为什么独立进程版的节点（bitcoin-node）可行：既然可执行文件只是库的壳，把壳拆开、用 IPC 库接线，功能上就是等价重组，这也是多进程设计的立足点。第三，为什么安全审计常从 consensus 与 kernel 两层读起：它们的依赖面最小、不碰网络与磁盘杂活，代码量占比小却承载全部有效性判定，单位审查精力的产出最高。

风险提示：本文为源码结构说明，二次开发与集成请先在测试环境验证；本文不构成投资建议。