誰在控制比特幣Core軟體？開發者揭露秘辛

前言：關於比特幣Core軟體，很多人因擴容之爭便片面地認為其開發是中心化的，而core開發者Jameson Lopp則想通過這篇文章來解釋Bitcoin Core的運作方式，並澄清比特幣是沒有控制者的，文中還提到了很多不為人知的秘辛。

以下為全文譯文：

關於誰有能力將代碼更改寫入Bitcoin Core庫的問題，時常會被提起。這些年來，各方都把此作為比特幣協議的「中心控制點」，但我認為，這個問題本身就是一個源於專制觀點的紅色鯡魚謬誤，這種模式並不適用於比特幣。 對於外行人來說，其中的原因當然不是顯而易見的，因此本文的目的就是解釋Bitcoin Core的運作方式，以及更高層次上的，關於比特幣協議的發展方式。

Bitcoin Core的歷史

Bitcoin Core是比特幣協議開發的焦點，它並不是命令和控制點。如果它因為任何原因而停止存在，那麼一個新的焦點將會出現，它基於的技術通信平台（當前為GitHub存儲庫）是源於方便問題，而不是定義/項目完整性的問題。事實上，我們已看到比特幣的開發曾發生過平台轉移，甚至是名字的更改！

在2009年初，比特幣項目的源代碼只是一個託管在SourceForge上的.rar文件。 早期開發人員實際上會通過電子郵件與中本聰交流代碼補丁。

2009年10月30日，Sirius（Martti Malmi）在SourceForge上為比特幣項目創建了一個subversion存儲庫；

2011年，比特幣項目從SourceForge遷移到GitHub；

2014年，比特幣項目被更名為Bitcoin Core；

不信任任何人

雖然這個組織存在一些GitHub「維護者」帳戶，它們能夠將代碼合併到主分支中，但這更像是一種清潔功能，而不是意味著權力地位。如果任何人都可以把代碼合併到主分支當中，那麼很快比特幣代碼庫就會淪為「太多廚師湧入廚房」的場景。Bitcoin Core遵循的是最小特權原則，即如果被濫用，任何賦予個人的權力都很容易被顛覆。

從對抗的角度來看，GitHub是不可去信任的。任何數量的GitHub員工都可以使用他們的管理許可權將代碼注入比特幣存儲庫，而無需維護人員的同意。但GitHub攻擊者也不太可能破壞Bitcoin Core維護者的PGP密鑰。

Bitcoin Core沒有將代碼的完整性建立在GitHub帳戶之外，而是具有一個連續的集成系統，它執行對可信PGP密鑰的檢查，每個合併提交都必須要有簽名。雖然這些密鑰與已知身份相關聯，但仍然不能安全地認為它總是如此，密鑰可能會受到損害，除非原始密鑰所有者通知其他維護者，否則我們就不會知道。因此，提交密鑰也不能提供完美的安全性，它們只會使攻擊者更難以注入任意代碼。

比特幣王國的鑰匙

在撰寫本文時，這些是值得信賴的PGP指紋：

這些密鑰對應著以下這5個人：

Wladimir J. van der Laan

Pieter Wuille

Jonas Schnelli

Marco Falke

Samuel Dobson

這是否意味著我們相信這五個人？不完全是。密鑰不是身份證明，這些密鑰可能落入其他人的手中。如果運行verify-

commits python腳本，你真正得到了什麼保證？

python3 contrib / verify-commits / verify-commits.py

使用來自bitcoin / contrib / verify-commits的verify-commits數據

所有Tree-SHA512s都匹配到

309bf16257b2395ce502017be627186b749ee749

有一條從「HEAD」到82bcf405f6db1d55b684a1f63a4aabad376cdad7的有效路徑，其中所有提交都已簽名！

verify-commits腳本是一個完整性檢查，任何開發人員都可以在他們的機器上運行。執行後，它會在2015年12月提交82bcf405之後檢查每次合併提交時的PGP簽名，在編寫時有超過3,400次合併。如果腳本成功完成，它告訴我們自那時以來已經更改的每一行代碼，都已通過比特幣核心開發過程並由具有維護者密鑰「簽字」。雖然這不是一個完美保證（即確保沒有人能注入惡意代碼（維護人員可能會出現流氓行為或者他們的密鑰被盜）），但它會大大減少攻擊面。至於維護者是幹什麼的，以及他們是如何實現這一角色的？我們稍後會深入研究。

分層安全性

Bitcoin Core代碼的完整性不能僅僅依賴於少數幾個密碼密鑰，這就是為什麼存在很多其他檢查的原因。這裡有很多安全層來提供深度防禦：

Pull請求安全性發布安全性

Gitian確定性構建系統是由多個開發人員獨立運行的，其目標是創建相同的二進位文件。如果有人設法創建與其他開發人員的構建不匹配的構建，則表明引入了非確定性，因此最終版本不會發生。如果存在非確定性，開發人員會找出出錯的地方，修復它，然後構建另一個候選版本。一旦確定性構建成功，那麼開發人員就會對生成的二進位文件進行簽名，從而保證二進位文件和工具鏈不被篡改且使用了相同的源。此方法刪除了構建和分發過程中的單點故障，任何具有技術技能的人都可以運行自己的構建系統，說明在這裡。

一旦Gitian構建完成，並得到了構建者簽署，一位 Bitcoin Core 的維護者將PGP簽署一個消息，其中包含每個構建的SHA256哈希值。如果您決定運行預先構建的二進位文件，則可以在下載後檢查其哈希值，然後使用哈希值驗證簽名版本消息的真實性。這樣做的說明可以在這裡找到。

以上所有內容都是開源的，並且任何具有技能和願望的人都可對其進行審核。

最後，即使在完成上述所有質量和完整性檢查之後，提交到Bitcoin Core並最終進入版本的代碼也不會被任何中心化的組織部署到節點網路上。相反，每個節點操作員必須有意識地決定更新他們運行的代碼。Bitcoin Core故意沒有設置自動更新功能，因此用戶可自行決定需要運行什麼版本的代碼。

儘管Bitcoin Core項目實施了以上所有技術安全措施，但它們並不是完美的，理論上它們中的任何一個都可能受到損害。Bitcoin Core代碼完整性的最後一道防線與任何其他開源項目相同，即開發者需時刻保持警惕，審查Bitcoin Core代碼的眼睛越多，惡意或有缺陷代碼進入發布版客戶端的可能性就越小。

代碼覆蓋率

Bitcoin Core有很多測試代碼，有一個針對每個PR運行的集成測試套件，以及一個每天晚上在master上運行的擴展測試套件。

你可以通過以下方式自行檢查測試的代碼覆蓋率：

克隆Bitcoin Core GitHub存儲庫；

安裝從源構建所需的依賴項；

運行這些命令；

在./total_coverage/index.html查看報告；

或者，你可以在此處查看Marco Falke主持的覆蓋報告。

具有如此高的測試覆蓋率，意味著代碼按照預期工作具有更高的確定性。

當涉及到共識關鍵軟體時，測試是一件大事。而對於特別複雜的更改，開發人員有時會執行艱苦的突變測試，也就是說，他們通過故意破壞代碼並查看測試是否如預期那樣失敗來進行測試。Greg Maxwell在討論0.15發行版時對這個過程給出了一些見解：

「測試是針對軟體的測試，那測試的測試又是什麼呢？要進行測試的測試，你必須去破壞軟體。」 – ?Greg Maxwell

自由市場競爭

BitMEX寫了一篇關於比特幣實現生態系統的優秀文章。當前有十多種不同的比特幣兼容實現，甚至還有更多的「競爭網路」實現。這是開源的自由，任何對Bitcoin Core項目不滿意的人，都可以自由地運行自己的軟體。他們可以從零開始，也可以選擇去分叉 Core軟體。

在編寫本文時，96%的比特幣節點是運行Bitcoin Core軟體的。為什麼會是這樣？如果切換到另一個軟體實現所需的工作量最小，那麼Bitcoin Core如何在節點網路上擁有近乎壟斷的地位？畢竟，很多其他實現提供了與Bitcoin Core兼容或至少高度相似的RPC API。

我相信這是Bitcoin Core成為發展重點的結果，它擁有數量級更多的開發人才和開發時間的支持，這意味著Bitcoin Core 項目的代碼往往是最具性能、最安全的。在資金管理方面，節點運營商不想要運行次好的軟體。此外，考慮到這是一種共識軟體，並且比特幣協議不具有正式的規範，所以使用焦點實現會更為安全（因為假設你運行的是其他版本的軟體，對於網路的大多數節點而言，你的節點可能就是一個bug）。從這個意義上來講，開發焦點的代碼與現有的規範是最接近的。

誰是Core開發者？

不熟悉 Bitcoin Core 開發過程的人，可能會從外部查看項目，並將Core視為一個整體實體。情況遠非如此！Core貢獻者之間經常存在著分歧，甚至最多產的貢獻者也編寫了大量從未被合併到項目中的代碼。如果你閱讀了關於貢獻的指導方針，你可能會注意到它們相當寬鬆，這個過程最好被描述為「粗略的共識」。

「維護人員將考慮補丁是否符合項目的一般原則；是否滿足包含的最低標準；以及將判斷貢獻者的一般共識。」

那Bitcoin Core的維護者是誰呢？他們是那些通過在一段時間內提供高質量貢獻，並且在項目中建立了足夠社會資本的貢獻者。當現有的維護人員組認為，某個貢獻者表現出的能力、可靠性和動機足以勝任，他們可授予該貢獻者GitHub帳戶的提交訪問權。而首席維護者的角色是負責監督項目的所有方面，並負責協調發布的人。這些年來，一共有三位首席維護者，他們分別是：

中本聰（Satoshi Nakamoto） 2009.1.3 – 2011.2.23

加文.安德烈斯（Gavin Andresen） 2011.2.23 – 2014.4.7

Wladimir van der Laan 2014.4.7 至今

充當Bitcoin Core維護者通常被稱為看門人，因為維護者實際上沒有權力做出違背貢獻者或用戶共識的決策。然而，由於整個生態系統的額外關注，這個角色擔負的壓力可能非常繁重。例如，Gregory Maxwell在2017年由於其個人原因放棄了他的維護者角色，這很可能是因為他在擴容爭論中經歷的公眾壓力。

Wladimir撰寫了一篇的文章，講述了作為Core維護者的壓力，以及為什麼應該刪除Gavin的提交訪問許可權，這讓很多人感到不安。

類似地，當Jeff Garzik的維護者許可權也被刪除時，他和其他人對此也感到了不適，但實際上Garzik已經有兩年沒有為 Core提供貢獻了。給他的GitHub帳戶保留core的維護權不會給項目帶來任何好處，這隻會造成安全風險，並且違反了Wladimir在他的帖子中提到的最低特權原則。

其他人可能看到Core所發生的一些事，便認為這是一個技術官僚主義組織或象牙塔，這使得新進入者很難加入。但如果你與貢獻者交談，你會發現情況並非如此。雖然在過去的幾年當中，只有十幾個人擁有提交訪問權，但有數百名開發人員為比特幣做出了貢獻。我自己也做了一些小的貢獻，當然我自認為自己不是一名「核心開發者」，但我的確是一名Core軟體開發者。沒有人能阻止你為比特幣做貢獻！

雖然Bitcoin Core 具有一些結構（它使用中心化的通信通道來協調），但是項目本身不受任何參與者的控制（甚至是那些升級了GitHub存儲庫特權的人）。即使維護者組織的政變在技術上可能劫持GitHub存儲庫，審查持不同意見的開發人員，甚至可能爭搶「Bitcoin Core」的品牌，但其結果是Bitcoin Core將不再是開發的焦點。不同意維護人員操作的開發人員只需分叉代碼，並將他們的工作轉移到不同的存儲庫，那麼Bitcoin Core維護者就沒有管理特權。

即使沒有發生「政變」，如果一個有爭議的改變確實以某種方式進入了Core軟體，一些開發人員會分叉軟體，刪除有爭議的改變，並使其可用於用戶。您可能會爭辯說，這正是Amaury Sechet分叉Bitcoin Core然後刪除隔離見證（SW）功能，並創建Bitcoin ABC所發生的事啊。或者，如果Core拒絕某些人想要的更改建議，開發人員可以分叉並添加這些更改。這種情況已經發生過很多次了，例如：

Mike Hearn 分叉了Core，並創建了Bitcoin XT；

Andrew Stone分叉了Core，並創建了Bitcoin Unlimited；

Jeff Garzik分叉了Core，並創建了BTC1；

分叉代碼是很容易的，但轉移比特幣開發的焦點卻是非常難的，你必須說服貢獻者，讓他們把時間花到不同的項目上去。

你也很難去說服很多不盲目遵循Bitcoin Core變化的用戶，這可能是一種自我加強的信念，因為如果用戶不通過保持對選項的了解來參與共識的過程，他們就會把部分權力讓給開發人員。然而，在2017年的UASF（用戶激活的軟叉）運動中，用戶的權力得到了行使。匿名比特幣開發者shaolinfry提出了BIP 148，它將迫使礦工在8月1日附近誕生的區塊激活隔離見證功能。然而，BIP 148被證明太具爭議，因此不能被Bitcoin Core所採用，所以shaolinfry分叉了Core軟體，並創建了 「Bitcoin UASF」 軟體，這個軟體實現獲得了非凡的牽引力，並似乎產生了足夠的壓力，以說服礦工採用BIP 91（在BIP 148截止日期之前）激活分叉。

在我看來，最好的Bitcoin Core貢獻者是那些實踐極端所有權的人。案例分析：儘管John Newbery並沒有編寫包含這個特定共識bug的代碼，但他卻因自己沒有仔細審查而感到自責。

我們都是中本聰。

為Bitcoin Core做貢獻

儘管有很多資源可以幫助有抱負的開發人員，但最開始為Core做貢獻時，會讓人感到畏懼。此處可以找到貢獻的指導方針：https://bitcoincore.org/en/faq/contributing-code/

當然，你可能也希望從 Jimmy Song的介紹入手。

Core開發者Eric Lombrozo還撰寫了一篇關於理解在Core存儲庫中如何進行更改的文章：

https://medium.com/@elombrozo/the-bitcoin-core-merge-process-74687a09d81d

在撰寫本文時，為了審計GitHub提交歷史的完整性，我在我的機器上運行verify-commit.py腳本時遇到了困難，一個特定的示例可能有用。為了防止未來的開發人員不得不處理這些問題，我打開了一個pull請求來改進文檔。從PR歷史中可以看出，4個不同的開發人員就如何改進我的pull請求提出了建議。這包括使用不同的wiki標記，簡化的bash命令，以及可以在verify-commit.py腳本中使用的新參數。我同意所有的建議都是有道理的，所以我把它們合併到我的代碼中，並推送了一個更新版的 pull 請求。此時，參與審查的開發人員承認，他們發現PR是可以接受的，維護人員Marco Falke將其標記為包含在0.18版本中。幾天過去了，開發人員沒有異議，代碼被維護人員Samuel Dobson合併到了Core軟體當中。

誰在控制比特幣？

正如我多年來廣泛爭論的那樣，完全將比特幣作為一個系統來理解幾乎是不可能的。比特幣的定義就像語言的定義。語言是自發產生的，關於詞語意義的共識是有機的，而不是字典所決定的。就像字典描述語言現象而不是定義它一樣，比特幣實現也用代碼描述比特幣的語言。沒有人被迫同意字典中給定單詞的定義，也沒有人通過運行比特幣而被強制同意給定比特幣實現中的代碼。

語言不受民主支配，比特幣也不受支配，雖然你可能聽到人們引用礦工、節點、開發者或用戶「投票」，但是沒有機制可使任何形式的多數投票能夠強迫少數反對者接受他們不同意的變更。比特幣是沒有統治者的，但其並非沒有規則，其規則是由網路上的各個參與者定義和實施的。

雖然比特幣協議本身的更改，通常是通過比特幣改進提案流程進行的，但即使它是推薦的最佳做法，也不會強迫任何人遵循它。它只是一種更為正式的方式，試圖通過同行評審和建立共識的過程來引導變革。

儘管這很難解釋和理解，但如果存在一個單一的控制點，那麼它也將是比特幣反脆弱性的一個關鍵方面，它也將是一個單一的失敗點，會被受比特幣威脅的強大實體所利用。最終，每個節點運營商通過確保網路上沒有其他人違反他們同意的規則來管理自己。這種安全模式是比特幣自下而上治理的基礎。

沒有人控制比特幣。

也沒有人控制比特幣開發的焦點。

最後，感謝John Newbery。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！