核心问题：在二元之下，验证信任

当大多数人下载比特币核心（Bitcoin Core）时，他们与构建系统的交互仅需几次点击。他们获取软件的可执行二进制文件，验证签名（希望如此！），然后开始运行比特币节点。他们立即看到的是运行中的软件。而他们没有看到的是产生该软件的构建系统和繁复的流程。一个代表比特币原则——去中心化、透明和可验证的构建系统。

在这背后，是多年的工程工作，旨在回答一个简单的问题：“为什么有人应该信任这份软件？” 答案是：你不必信任。你应该能够验证。

在软件供应链攻击成为全球头条的时代，从被篡改的npm包、后门库、流氓CI服务器，到比特币核心的构建流程，都是一种安静的自律项目。它的方法可能比“推送即部署”的无阻便利显得缓慢而复杂，但这正是重点。安全性不是便利的。

要理解比特币核心的构建系统，我们应当了解：

• 比特币核心的构建系统理念
• 可复现的构建
• 最小化依赖
• 无自动更新
• 持续集成
• 持续适应

比特币核心的构建系统理念

谈到比特币的去中心化，大多数人关注矿工、节点和开发者。但去中心化并不止于协议的参与者。它还延伸到软件本身的构建和分发方式。

比特币生态系统中的一项原则是“不要信任，验证”。运行自己的节点是一种验证行为，检查每个区块和交易是否符合共识规则。而构建系统本身也为你提供了另一种验证的机会，在软件层面。比特币是一种没有受信中介的货币，比特币核心旨在成为没有受信构建者的软件。构建系统极力确保任何人、任何地方都能独立重建出与bitcoincore.org网站上相同的二进制文件。

这一理念可以追溯到Ken Thompson在1984年发表的论文《信任的反思》（Reflections on Trusting Trust），该论文警告即使是看似干净的源代码，也不能保证可信，如果构建该软件的编译器本身被篡改。比特币的开发者们铭记这一教训。正如比特币核心贡献者Michael Ford（fanquake）所说：

“可复现的构建至关重要，因为我们的软件用户不应相信里面的内容就是我们所说的。这必须始终是可以独立验证的。”

这既是技术目标，也是比特币精神的一部分。

在安全领域，人们谈论“攻击面”。比特币核心的构建系统将构建过程本身视为一个攻击面，旨在最小化和防御。

可复现的构建：全程验证

比特币核心版本的生产流程始于GitHub上的开源代码库。每一次更改都是公开的。每个拉取请求都经过审查。但从人类可读的_代码_到可运行的二进制_软件_的过程，涉及编译器、第三方库和操作系统，这些都可能成为篡改、后门或错误的潜在载体。

“受信任的第三方是安全漏洞”——Nick Szabo（2001）

为应对这些担忧，比特币核心设计了一个使用Guix的构建流程管道。Guix是一个包管理器，旨在创建可复现、确定性的软件环境。

当一个新的比特币核心版本被标记时，多个独立贡献者会使用Guix从零开始构建二进制文件。每个构建者都在一个隔离的环境中工作，保证工具链、编译器版本和系统库完全一致。如果所有构建者都生成相同的输出，就说明构建是确定性的。

然后，贡献者会对生成的二进制文件进行密码学签名，并将签名发布在一个名为‘guix.sigs’的GitHub仓库中，列出每个比特币核心版本的验证信息。有些构建者是比特币核心开发者，但这不是必需的，因为验证过程对公众开放。实际上，许多非代码贡献者也会定期贡献签名。

这个过程被称为“可复现的构建”，它是对Thompson“信任的信任”的解药。意味着任何人都可以拿到开源代码、相同的Guix环境，独立确认官方二进制文件与自己构建的是否一致。虽然可复现的构建可以验证软件是否真实反映了源代码，但软件的正确性还依赖于全面的测试和代码审查流程。

大多数人永远不会进行完整的编译，也不会检查Guix清单或比对构建哈希值。他们不需要。基础设施的存在，以及维护它的人，为每个用户提供了可信的基础。

bitcoincore.org上的官方二进制文件不仅仅是“由比特币核心维护者生产的”。它们是众多独立构建者输出的交集。你最终下载的，就是大家共同构建和验证过的真实版本。

这就是全程验证。

最小化依赖：少一些信任

可复现性是其中一方面，另一面是减少需要复现的内容。比特币核心的代码并不是运行比特币核心时唯一执行的代码。比特币核心还依赖外部第三方代码和库，以加快开发和提高效率。

过去十年，比特币核心开发者不断剥离这些不必要且有时存在问题的第三方依赖，比如OpenSSL和MiniUPnP。无论是外部库还是工具包，这些依赖都增加了复杂性或隐藏了假设。像Boost和Libevent这样的项目，曾经是核心代码库的主力，现在逐步被淘汰或用更简单的自包含替代品取代。

为什么？因为每增加一个依赖，就增加了供应链风险。这是你没有自己写、没有审计、无法完全控制的代码。减少依赖让构建系统更轻、更安全，也更易于验证。

Brink最近在其“最小化依赖”博客文章中强调了这一点[1]，指出这不仅关乎简洁，更关乎项目的安全和自主性。每移除一个依赖，项目就少一个必须信任的外部方，也少一个潜在的后门。

最终目标是生成完全静态的二进制文件：包含运行所需一切的可执行文件，没有动态或运行时依赖。这种自包含意味着不依赖于可能因操作系统不同而变化的外部库。

在一个大多数软件变得越来越庞大、依赖中心化包生态系统的世界里，比特币核心正朝相反的方向前进：追求极简和自主。

无自动更新

在大多数现代软件中，用户无需关心软件版本的更新决策，软件会在后台自动安静地更新到最新版本。虽然这很方便，但与比特币核心的理念背道而驰。

比特币核心从未包含自动更新功能，开发者也表示永远不会。自动更新会集中权力，形成一个可以向每个节点推送（潜在恶意）代码的单一集团。这正是比特币设计时要避免的中心化控制。通过要求用户手动下载、验证和安装新版本，比特币核心强化了个人责任和可验证的同意。

构建系统和无自动更新是同一原则的两个方面。只有节点运行者决定运行什么，并能验证所运行软件的真实性。

持续集成：慢一点，修正问题

在硅谷，持续集成（CI）和持续部署（CD）是敏捷开发的标志。快速发布。更快迭代。让自动化完成其余工作。

比特币核心采取不同的方法。其持续集成系统不是为了加快部署，而是为了保障完整性。自动化构建测试跨平台的一致性。比特币核心的构建系统尽可能对硬件和操作系统保持中立。项目可以为Linux、macOS和Windows构建二进制文件，也支持多种架构，包括x86_64、aarch64（ARM）甚至riscv64。持续集成系统通过对每个提议的变更执行数百项测试，确保兼容性和软件完整性。

其结果是形成一种文化：“持续集成”意味着持续测试、验证和安全，而非持续创新。

慢一点，修正问题。

持续适应：我们还没完？

构建系统不是静态的。开发者不断优化它，减少依赖、改进跨架构构建，并探索未来完全静态、零运行时依赖的构建方案。

虽然比特币核心的构建系统追求确定性，但它本身不能一成不变。它所处的世界不断变化。操作系统、编译器、库和硬件架构都在变化。每次macOS或glibc的新版本、每个编译器标志的废弃，甚至新兴的CPU架构，都可能引入微妙的不兼容问题，必须解决。一个停滞的构建系统，随着时间推移，将无法正常构建。

可复现的构建的悖论在于，它们需要不断演进，才能保持可复现性。开发者必须不断锁定、修补，有时还要更换工具链，以在不断变化的背景下保持确定性。维护稳定与适应性之间的平衡，是比特币持续韧性的关键部分。

立即获取你的《核心问题》！

**不要错过拥有《核心问题》**的机会——其中包含许多核心开发者撰写的文章，讲述他们自己参与的项目！

这篇文章是比特币杂志最新印刷版《核心问题》中的编辑信。我们在这里提前分享，作为对全文内容的预览。

[1]