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

摘要： 前言：關於比特幣Core軟體，很多人因擴容之爭便片面地認為其開發是中心化的，而core開發者Jameson Lopp則想通過這篇文章來解釋Bitcoin Core的運作方式，並澄清比特幣是沒有控制者的，文中還提到了很多不為人知的祕辛。 以下為全文譯文： 關於誰有能力將程式碼更改寫入Bi...

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

以下為全文譯文：

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

Bitcoin Core的歷史

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

1.  在2009年初，比特幣專案的原始碼只是一個託管在SourceForge上的.rar檔案。 早期開發人員實際上會通過電子郵件與中本聰交流程式碼補丁。
2. 2009年10月30日，Sirius（Martti Malmi）在SourceForge上為比特幣專案建立了一個subversion儲存庫；
3. 2011年，比特幣專案從SourceForge遷移到GitHub；
4. 2014年，比特幣專案被更名為Bitcoin Core；

不信任任何人

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

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

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

比特幣王國的鑰匙

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

1、71A3B167355025D447E8F274810B012346C9A6 2、133EAC179436F14A5CF1B794860FEB804E669320 3、32EE5C4C3FA15CCADB46ABE529D4B6416F53EC 5、B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B 6、CA03882CB1FC067B5D3ACFE4D300116E1C875A3D

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

1. Wladimir J. van der Laan <[email protected]>
2. Pieter Wuille <[email protected]>
3. Jonas Schnelli <[email protected]>
4. Marco Falke <[email protected]>
5. Samuel Dobson <[email protected]>

這是否意味著我們相信這五個人？不完全是。金鑰不是身份證明，這些金鑰可能落入其他人的手中。如果執行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請求安全性

1. 任何人都可以通過在bitcoin/bitcoin上開啟針對主分支的pull請求，並自由地提出程式碼更改以改進軟體。
2. 開發人員稽核pull請求，以確保它們無害。任何人都可自由地審查pull請求並提供反饋。在為Bitcoin Core做出貢獻時，是沒有看門人或入學考試的。如果一個pull請求，它的確是有用的，並且對其沒有合理的反對意見，那麼維護者就會將其合併到core軟體。
3. Core維護者設定此 ofollow,noindex" target="_blank">預push鉤 ，以確保它們不會將未簽名的提交推送到儲存庫中。
4. 可選擇通過 OpenTimestamps 對合並提交安全地新增時間戳；
5. Travis Continuous Integration系統 定期執行 此指令碼 以檢查git樹（歷史）完整性，並驗證master分支中的所有提交是否都使用其中一個可信PGP金鑰進行簽名；
6. 任何想要執行 此指令碼 以驗證所有合併提交PGP簽名的人，都可以追溯到2015年12月。我在撰寫本文時運行了它，而在我的膝上型電腦上，這個過程需要25分鐘。

釋出安全性

1. Gitian 確定性構建系統是由多個開發人員獨立執行的，其目標是建立相同的二進位制檔案。如果有人設法建立與其他開發人員的構建不匹配的構建，則表明引入了非確定性，因此最終版本不會發生。如果存在非確定性，開發人員會找出出錯的地方，修復它，然後構建另一個候選版本。一旦確定性構建成功，那麼開發人員就會對生成的二進位制檔案進行簽名，從而保證二進位制檔案和工具鏈不被篡改且使用了相同的源。此方法刪除了構建和分發過程中的單點故障，任何具有技術技能的人都可以執行自己的構建系統，說明 在這裡 。
2. 一旦Gitian構建完成，並得到了構建者簽署，一位 Bitcoin Core 的維護者將PGP簽署一個訊息，其中包含每個構建的SHA256雜湊值。如果您決定執行預先構建的二進位制檔案，則可以在下載後檢查其雜湊值，然後使用雜湊值驗證簽名版本訊息的真實性。這樣做的說明可以在 這裡找到 。
3. 以上所有內容都是開源的，並且任何具有技能和願望的人都可對其進行稽核。
4. 最後，即使在完成上述所有質量和完整性檢查之後，提交到Bitcoin Core並最終進入版本的程式碼也不會被任何中心化的組織部署到節點網路上。相反，每個節點操作員必須有意識地決定更新他們執行的程式碼。 Bitcoin Core故意沒有設定自動更新功能，因此使用者可自行決定需要執行什麼版本的程式碼。

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

程式碼覆蓋率

Bitcoin Core有很多測試程式碼，有一個針對每個PR執行的整合測試套件，以及一個每天晚上在master上執行的擴充套件測試套件。

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

1. 克隆Bitcoin Core GitHub儲存庫；
2. 安裝從源構建 所需的依賴項 ；
3. 執行 這些命令 ；
4. 在./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帳戶的提交訪問權。而首席維護者的角色是負責監督專案的所有方面，並負責協調發布的人。這些年來，一共有三位首席維護者，他們分別是：

1. 中本聰（Satoshi Nakamoto） 2009.1.3 - 2011.2.23
2. 加文.安德烈斯（Gavin Andresen） 2011.2.23 - 2014.4.7
3. 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拒絕某些人想要的更改建議，開發人員可以分叉並新增這些更改。這種情況已經發生過很多次了，例如：

1.  Mike Hearn 分叉了Core，並建立了Bitcoin XT；
2. Andrew Stone分叉了Core，並建立了Bitcoin Unlimited；
3. 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。