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

当大多数人下载 Bitcoin Core 时，他们与构建系统的互动仅需几次点击。他们获取软件的可执行二进制文件，验证签名（希望如此！），并开始运行比特币节点。他们立即看到的是正在运行的软件。他们看不到的是生成该软件的构建系统和广泛的过程。一个代表比特币去中心化、透明度和可验证性的原则的构建系统。

在该下载背后，隐藏着多年工程工作的成果，旨在回答一个简单的问题：“为什么任何人都应该信任这款软件？”答案是：你不应该必须信任。你应该能够验证。

在软件供应链攻击登上全球头条的时代，从受损的 npm 包、后门库到非法 CI 服务器，比特币核心的构建过程作为一个安静的纪律项目而存在。与“推送部署”的无摩擦便利相比，它的方法可能显得缓慢和复杂，但这正是关键。安全并不方便。

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

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

比特币核心的构建系统哲学

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

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

这一理念可以追溯到肯·汤普森（Ken Thompson）在1984年发表的论文《关于信任的反思》（Reflections on Trusting Trust），其中警告说，即使是看起来干净的源代码，如果构建该软件的编译器本身被攻破，也不能被信任。比特币的开发者深刻领悟了这一教训。正如比特币核心贡献者迈克尔·福特（Michael Ford，fanquake）所言：

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

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

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

可复现的构建：验证从头到尾

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

“受信任的第三方是安全漏洞” — 尼克·萨博（Nick Szabo，2001）

为了解决这些问题，比特币核心构建了一个使用 Guix 的构建过程管道，Guix 是一个旨在创建可复现、确定性软件环境的包管理器。

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

贡献者然后对生成的二进制文件进行加密签名，并在单独的 GitHub 存储库“guix.sigs”上发布这些签名，该存储库列出了每个比特币核心版本的这些证明。有些构建者是比特币核心的开发者，但这并不是一个要求，因为证明过程对公众开放。事实上，许多非代码贡献者定期贡献签名。

这个过程被称为可复现的构建，它是汤普森的“信任信任”的解药。这意味着任何人都可以使用开源代码、相同的 Guix 环境，独立确认官方二进制文件与他们自己构建的相匹配。虽然可复现的构建可以验证软件确实是软件源代码的真实表示，但软件的正确性则依赖于周密的测试和代码审查过程。

大多数人永远不会执行完整的编译，也不会检查 Guix 清单或比较构建哈希。他们不需要这样做。该基础设施的存在，以及维护它的人，给每个用户提供了一个值得信赖的基础。

在 bitcoincore.org 上的官方二进制文件不仅仅是“由比特币核心维护者生成”。它们是数十个独立构建者输出的交集。你最终下载的就是其他人构建并验证为真实的内容。

验证从头到尾。

最小化依赖：减少信任

可复现性是方程的一方面。另一方面是最小化需要重现的内容。比特币核心的代码并不是运行比特币核心时执行的唯一代码。比特币核心还依赖外部的第三方代码和库，以加快开发和提高生产力。

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

为什么？因为你继承的每个依赖都是潜在的供应链风险。这是更多你没有编写、没有审计、也无法完全控制的代码。减少依赖使构建系统更精简、更安全、更容易验证。

Brink 最近在其“最小化依赖”博客文章中强调了这一努力，指出这不仅仅是简单性的问题，而是关于维护项目的安全性和自主性。每去除一个依赖，就是减少一个需要信任的外部方，也是减少一个潜在的后门。

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

在一个大多数软件变得越来越臃肿并依赖于集中式包生态系统的世界中，比特币核心正朝着简约和独立的方向发展。

无自动更新

在大多数现代软件中，用户不需要担心更新到哪个软件版本，或是否更新软件。你安装一个应用程序，它会在后台静默自动更新到最新版本。虽然这很方便，但与比特币核心的哲学背道而驰。

比特币核心从未包含自动更新，开发者表示它永远不会包含。自动更新集中权力。它们创建了一个可以将（潜在恶意）代码推送到网络上每个节点的单一群体。这正是比特币旨在避免的集中控制。通过要求用户手动下载、验证和安装新版本，比特币核心加强了个人责任和可验证的同意。

构建系统和缺乏自动更新是同一原则的两部分。只有节点运行者决定运行什么，并可以验证所运行的软件是可信的。

持续集成：缓慢推进，修复问题

在硅谷，持续集成和持续部署（CI/CD）是敏捷软件开发的标志。快速交付。更快迭代。让自动化做其余的事情。

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

结果是一个文化，在这里“持续集成”意味着持续测试、验证和安全，而不是持续创新。

缓慢推进，修复问题。

持续适应：我们完成了吗？

构建系统不是静态的。开发者继续通过减少依赖、改善跨架构构建以及探索完全静态构建的未来，来不断完善它。

尽管比特币核心的构建系统力求确定性，但构建系统本身不能是静态的。它所处的世界在不断变化。操作系统、编译器、库和硬件架构都在变化。每个新的 macOS 或 glibc 版本、每个编译器标志的弃用或新兴的 CPU 架构都会引入微妙的不兼容性，必须加以解决。一个静止不动的构建系统，随着时间的推移，将不再能够构建。

可复现构建的悖论在于，它们需要不断演变才能保持可复现性。开发者必须不断固定、修补，有时甚至替换工具链，以保持确定性，抵御变化的背景。维护稳定性和适应性之间的平衡是比特币持续韧性的一部分。

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

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

这篇文章是比特币杂志最新印刷版《核心问题》中的编辑信件。我们在这里分享它，以提前了解整个期刊中探讨的思想。

[1]