核心問題：在二元之下，驗證信任

當大多數人下載比特幣核心（Bitcoin Core）時，他們與構建系統的互動僅需幾次點擊。他們取得軟體的可執行二進位檔，驗證簽名（希望如此！），然後開始運行比特幣節點。他們立即看到的是運行中的軟體。而他們沒有看到的是產生該軟體的構建系統和繁複的流程。一個代表比特幣去中心化、透明性和可驗證性原則的構建系統。

在這背後，是多年工程工作，旨在回答一個簡單的問題：「為什麼有人應該信任這個軟體？」答案是：你不必信任。你應該能夠驗證。

在軟體供應鏈攻擊成為全球焦點的時代，從被破壞的 npm 套件、後門庫、流氓 CI 伺服器，到比特幣核心的構建流程，這是一個安靜而有紀律的專案。它的方法可能比“推送部署”那樣的無摩擦便利來得慢且複雜，但這正是重點。安全性並不方便。

要理解比特幣核心的構建系統，我們應該了解：

• 比特幣核心的構建系統理念
• 可重複構建（Reproducible Builds）
• 最小化依賴
• 無自動更新
• 持續整合（CI）
• 持續適應

比特幣核心的構建系統理念

談到比特幣的去中心化，大多數人專注於礦工、節點和開發者。但去中心化並不止於協議的參與者。它延伸到軟體本身的構建與分發方式。

比特幣生態系的一個原則是“不要信任，驗證”。運行自己的節點是一種驗證行為，檢查每個區塊和交易是否符合共識規則。但構建系統本身也提供了另一個驗證的機會，即在軟體層面。比特幣是沒有信任中介的貨幣，比特幣核心致力於成為沒有信任建造者的軟體。構建系統竭盡所能，確保任何人、任何地方都能獨立重建出與 bitcoincore.org 網站上相同的二進位檔。

這一理念可以追溯到 Ken Thompson 在 1984 年的文章 Reflections on Trusting Trust，該文章警告即使是乾淨的源碼，如果用來編譯軟體的編譯器被破壞，也無法信任。比特幣的開發者將這個教訓銘記於心。正如比特幣核心貢獻者 Michael Ford（fanquake）所說：

“可重複構建至關重要，因為我們的軟體用戶不應該必須相信裡面內容就是我們所說的。這必須始終是可以獨立驗證的。”

這既是技術目標，也是比特幣精神的一部分。

在安全領域，人們談論“攻擊面”。比特幣核心的構建系統將構建過程本身視為一個攻擊面，並致力於最小化與防禦。

可重複構建：全程驗證

產出比特幣核心版本的流程始於 GitHub 上的開源程式碼庫。每個變更都是公開的。每個拉取請求都經過審查。但從人類可讀的 程式碼 到可執行的二進位 軟體，涉及編譯器、第三方庫和作業系統，這些本身都可能成為篡改、後門或錯誤的向量。

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

為了解決這些問題，比特幣核心設計了一個使用 Guix 的構建流程管道。Guix 是一個包管理器，旨在創建可重複、確定性軟體環境。

當一個新的比特幣核心版本被標記時，多個獨立貢獻者會用 Guix 從零開始構建二進位檔。每個構建者都在隔離的環境中工作，保證工具鏈、編譯器版本和系統庫完全一致。如果所有構建者產出相同的比特幣二進位檔，則表示構建是確定性的。

然後，貢獻者會對產生的二進位檔進行密碼簽名，並將簽名發布在另一個 GitHub 儲存庫 ‘guix.sigs’ 上，列出每個版本的驗證證明。有些構建者是比特幣核心的開發者，但這並非必要，因為驗證流程對所有人開放。事實上，許多非程式碼貢獻者也會定期提供簽名。

這個流程被稱為可重複構建，是 Thompson “信任的信任” 的解藥。它讓任何人都可以拿到開源碼、相同的 Guix 環境，獨立確認官方二進位與自己構建的是否一致。雖然可重複構建能驗證軟體是否真實反映源碼，但軟體的正確性仍依賴於徹底測試和程式碼審查。

大多數人不會進行完整的編譯，也不會檢查 Guix 配方或比對構建哈希值。他們不需要。這些基礎設施的存在，以及維護它們的人，為每個用戶提供了一個值得信賴的基礎。

bitcoincore.org 上的官方二進位檔不僅僅是“由比特幣核心維護者產出”。它們是數十個獨立構建者產出的交集。你最終下載的，就是大家都已經構建並驗證為正品的版本。

這是全程驗證。

最小化依賴：少一些信任

可重複性是其中一個方面，另一個則是盡量減少需要重複的部分。比特幣核心的程式碼並非運行比特幣時唯一執行的程式碼。比特幣核心還依賴外部第三方的程式庫和工具，以加快開發和提升效率。

過去十年，比特幣核心開發者持續剝除這些不必要且有時帶來問題的第三方依賴，如 OpenSSL 和 MiniUPnP。無論是外部庫還是工具包，這些依賴都會增加複雜性或引入隱藏假設。像 Boost 和 Libevent 這些曾是核心程式碼的重要組成部分，逐漸被淘汰或用更簡單的自包含替代品取代。

為什麼？因為每一個依賴都是潛在的供應鏈風險。這是你沒有自己寫、也沒審核、無法完全控制的程式碼。減少依賴讓構建系統更精簡、更安全，也更容易驗證。

Brink 最近在其“Minimizing Dependencies”部落格文章中提到[1]，指出這不僅是為了簡化，更是為了維護專案的安全與自主。每移除一個依賴，都是少一個外部信任方，也少一個後門的可能。

最終目標是產出完全靜態二進位檔：包含所有運行所需內容的可執行檔，沒有動態或運行時依賴。這種自我封閉的特性，意味著不依賴可能因作業系統不同而異的外部庫。

在一個大多數軟體越來越重、越來越依賴集中式套件生態系的世界裡，比特幣核心正朝相反的方向前進：追求極簡與獨立。

無自動更新

在大多數現代軟體中，用戶不需決定更新到哪個版本，或是否要更新。你安裝一個應用程式，它會在背景中悄悄自動更新到最新版本。雖然這很方便，但與比特幣核心的理念背道而馳。

比特幣核心從未包含自動更新功能，開發者也表示永遠不會。有自動更新就意味著權力集中。它們會產生一個能向所有節點推送（可能是惡意）程式碼的單一團隊。這正是比特幣要避免的中心化控制。通過要求用戶手動下載、驗證並安裝新版本，比特幣核心強化了個人責任與可驗證的同意。

構建系統與無自動更新是同一原則的兩個方面。只有節點運行者決定運行什麼，並能驗證所運行的軟體是否正品。

持續整合：慢慢來，修修補補

在矽谷，持續整合（CI）和持續部署（CD）是敏捷開發的標誌。快速交付。更快迭代。讓自動化完成其餘工作。

比特幣核心採取不同策略。其 CI 系統不是為了加快部署，而是為了保障完整性。自動化構建測試跨平台的一致性。比特幣核心的構建系統盡可能對硬體和作業系統保持中立。該專案可以為 Linux、macOS 和 Windows 構建二進位檔，也支援多種架構，包括 x86_64、aarch64（ARM）甚至 riscv64。持續整合系統確保這些相容性，以及通過數百次測試來確保軟體完整性。

結果是形成一種文化：所謂的“持續整合”意味著持續測試、驗證與安全，而非持續創新。

慢慢來，修修補補。

持續適應：我們完成了嗎？

構建系統並非一成不變。開發者持續優化它，減少依賴、改善跨架構構建，並探索完全靜態構建的未來，實現零運行時依賴。

雖然比特幣核心的構建系統追求確定性，但它本身不可能是靜態的。它所處的世界不斷變化。作業系統、編譯器、庫和硬體架構都在變。每次 macOS 或 glibc 的新版本、每次編譯器旗標的棄用，或新興的 CPU 架構，都會帶來微妙的不兼容問題，必須解決。一個停滯不前的構建系統，最終將無法再構建。

可重複構建的悖論在於，它們需要不斷演進，才能保持可重複性。開發者必須不斷固定版本、修補，甚至更換工具鏈，以在變化的背景下維持確定性。維持穩定與適應性之間的平衡，是比特幣持續韌性的一部分。

立即取得《核心議題》的副本！

不要錯過擁有 The Core Issue 的機會 — 裡面收錄了許多核心開發者親自撰寫的文章，解釋他們所從事的專案！

這篇文章是比特幣雜誌最新印刷版《核心議題》中的編輯信。我們在此提前分享，讓讀者了解整期內容所探討的思想。

[1]