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

当大多数人下载 Bitcoin Core 时，他们与构建系统的交互往往只需要几下点击就结束了。他们获取软件的可执行二进制文件，验证一个签名（希望如此！），然后开始运行一个比特币节点。眼前看到的是正在运行的软件。看不到的是：产生这些软件的构建系统以及大量复杂流程。一个体现比特币去中心化、透明性和可验证性原则的构建系统。

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

在软件供应链攻击登上全球头条的时代，从被攻陷的 npm 包、被植入后门的库、到肆意作祟的 CI 服务器，Bitcoin Core 的构建流程却像一项克制而安静的工程实践。它的方法可能看起来比“推送部署（push to deploy）”那种无摩擦的便利要慢且复杂，但关键恰恰在于此。安全并不方便。

要理解 Bitcoin Core 的构建系统，我们应该理解：

• Bitcoin Core 的构建系统理念
• 可复现构建
• 最小化依赖
• 不自动更新
• 持续集成
• 持续适应

Bitcoin Core 的构建系统理念

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

比特币生态系统中的一个原则是“不要信任，验证”。运行你自己的节点是一种验证行为：依据共识规则检查每一个区块和每一笔交易。但构建系统本身也为你提供了另一个在软件层面进行验证的机会。比特币是没有受信任中介的钱，而 Bitcoin Core 的目标则是构建出不依赖受信任构建者的软件。构建系统会花费巨大精力，确保任何人、在任何地方，都能独立地复现与 bitcoincore.org 网站上出现的完全相同的二进制文件。

这种理念可以追溯到 Ken Thompson 在 1984 年发表的论文 Reflections on Trusting Trust，它警告说：如果用于构建该软件的编译器本身已被篡改，那么即便源代码看起来干净，也仍然不能被信任。Bitcoin 的开发者将这一教训铭记于心。正如 Bitcoin Core 贡献者 Michael Ford（fanquake）所言：

“可复现构建至关重要，因为我们软件的任何用户都不应当被要求去信任：其中包含的东西就是我们所说的那样。它必须始终能够被独立验证。”

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

在安全领域，人们会谈论“攻击面”。Bitcoin Core 的构建系统则把构建过程本身视为需要被最小化并加以防守的攻击面。

可复现构建：一路向下的验证

生产一次 Bitcoin Core 发行版的流程从 GitHub 上的开源代码库开始。每一次变更都是公开的。每一个拉取请求都会被审查。但从人类可读的 代码 到可运行的二进制 软件，其中会涉及编译器、第三方库以及操作系统——而这些本身都可能成为被篡改、植入后门或引入错误的潜在途径。

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

为了解决这些顾虑，Bitcoin Core 架构出一套使用 Guix 的构建流程流水线。Guix 是一种包管理器，旨在创建可复现、确定性的软硬件环境。

当新的 Bitcoin Core 发行版被打上标签后，多个独立的贡献者会使用 Guix 从零开始构建出二进制文件。每一位构建者都在一个隔离的环境中工作，能够保证完全一致的工具链、编译器版本和系统库。如果所有构建者都生成了相同位元（bit）的输出，他们就知道构建是确定性的。

接着，贡献者会对生成的二进制文件进行加密签名，并把这些签名发布到一个单独的 GitHub 仓库 ‘guix.sigs’ 中。该仓库会为 Bitcoin Core 的每一次发行列出这些证明（attestations）。有些构建者是 Bitcoin Core 的开发者，但这不是要求；因为证明流程对公众是开放的，任何人都可以参与。事实上，许多并非代码贡献者的人也会定期提供签名。

这个过程被称为可复现构建，它是对 Thompson 所说“信任式信任（trusting trust）”的解药。它意味着任何人都可以拿到开源代码、相同的 Guix 环境，并独立确认：官方二进制文件确实与他们自己构建出来的一致。虽然可复现构建可以验证软件确实是对源代码的软件表示，但软件的正确性仍然交由围绕彻底测试和代码审查的流程来保障。

大多数人永远不会进行完整的编译，也不会检查 Guix 的清单，或对比构建哈希。他们不需要这么做。因为存在这套基础设施，以及维护它的人，每一位用户都能获得建立在“已获得的信心”之上的基础。

在 bitcoincore.org 上的官方二进制文件，不仅仅是“由 Bitcoin Core 维护者生成”。它们是许多独立构建者的输出的交汇点。最终你下载到的，就是每个人都构建并验证为真实可信的结果。

这是一条一路向下的验证链。

最小化依赖：更少需要信任的东西

可复现性只是等式的一面。另一面是：尽可能减少需要被复现的内容。运行 Bitcoin Core 时，不只是执行 Bitcoin Core 的代码。Bitcoin Core 还依赖外部的第三方代码和库，以加速开发并提升生产力。

在过去十年里，Bitcoin Core 的开发者持续剥离这些不必要且有时还会带来问题的第三方依赖，例如 OpenSSL 和 MiniUPnP。无论是外部库还是工具包，这些依赖都会增加复杂度，或者引入隐藏的假设。像 Boost 和 Libevent 这类曾经是 Core 代码库“主力”的项目，正逐步被淘汰或替换为更简单、可自包含的替代方案。

为什么？因为你继承的每一个依赖都可能带来供应链风险。那意味着：更少的是你亲自编写的东西，更多是你没有编写、没有审计、也无法完全控制的代码。减少依赖会让构建系统更精简、更安全，也更容易被验证。

Brink 最近在其“最小化依赖（Minimizing Dependencies）”的博客文章[1]中强调了这项努力，指出这不仅关乎简化，更关乎维护项目的安全性与自主性。每移除一个依赖，就等于减少了项目必须信任的一个外部方，也减少了后门的一个潜在入口。

最终目标是生产完全静态的二进制文件：可执行程序包含运行所需的所有内容，不存在任何动态或运行时依赖。这种自包含意味着：不再依赖那些可能在不同操作系统之间发生差异的外部库。

在一个大多数软件都越来越“厚重”、越来越依赖集中式包生态的世界里，Bitcoin Core 正朝着相反的方向前进：走向极简主义与独立性。

不自动更新

在大多数现代软件中，用户被屏蔽了“要更新到哪个软件版本”的决策，或甚至“是否要更新软件”的决策。你安装一个应用，它会在后台悄悄地、自动地把自己更新到最新版本。尽管这很方便，但却与 Bitcoin Core 的理念背道而驰。

Bitcoin Core 从未内置自动更新，开发者也表示从来不会加入。自动更新会集中权力。它们会形成一个单一的群体：可以把（可能是恶意的）代码推送到网络上的每一台节点。这正是比特币所刻意要避免的那种集中式控制。通过要求用户手动下载、验证并安装新版本，Bitcoin Core 强化了个体责任以及可验证的同意。

构建系统以及缺乏自动更新，是同一原则的两个部分。只有节点运行者决定要运行什么，并且能够验证被运行的软件确实是可信的、真实的。

持续集成：慢下来，并把事情修好

在硅谷，持续集成与持续部署（CI/CD）是敏捷软件开发的标志。快点交付。迭代得更快。让自动化把其余的都做掉。

Bitcoin Core 采取了不同的做法。它的 CI 系统存在的目的并不是为了加速部署，而是为了保障完整性。自动化构建会在不同平台间测试一致性。Bitcoin Core 的构建系统被设计成尽可能与硬件和操作系统无关。该项目可以为 Linux、macOS 和 Windows 构建二进制文件，也可以为多种架构构建，包括 x86_64、aarch64（ARM），甚至 riscv64。持续集成系统通过为每一个拟议变更执行数百项测试，来确保这种兼容性以及软件完整性。

其结果是一种文化：当人们说“持续集成”，指的是持续测试、持续验证与持续安全，而不是持续创新。

慢下来，并把事情修好。

持续适应：我们做好了吗？

构建系统并不是静态的。开发者会继续通过减少依赖、改进跨架构构建，并探索在零运行时依赖条件下的完全静态构建未来来对其进行精炼。

尽管 Bitcoin Core 的构建系统力求确定性，但构建系统本身不可能是静态的。它运行所处的世界一直在变化。操作系统、编译器、库和硬件架构都会演进。macOS 或 glibc 的每一次新发布、编译器标志的每一次弃用，以及新出现的 CPU 架构，都可能引入细微的不兼容，这些都必须被处理。一个原地不动的构建系统，随着时间推移将最终连构建都无法继续完成。

可复现构建的悖论在于：它们需要持续演进才能保持可复现。开发者必须不断对工具链进行钉住（pin）、打补丁，甚至在某些情况下替换工具链，以便在变化不断涌来的背景下维持确定性。在稳定性与适应性之间保持这种平衡，本身就是比特币持续韧性的组成部分。

今天就获取《The Core Issue》吧！

不要错过你拥有 The Core Issue 的机会 —— 其中包含许多 Core 开发者撰写的文章，讲述他们亲自参与推进的项目！

这篇文章是《Bitcoin Magazine》的最新 Print 版中收录的编辑部来信（The Core Issue 中的 Letter from the Editor）。我们在此提前分享它，以便你先睹全刊在探讨的那些想法。

[1]