原標題：《乾貨| 不完整比特幣開發史（上）：簡述》
要想完全理解比特幣開發現狀背後的原因，就不能不了解一些歷史事件。本文著重列舉了中本聰離開這個項目前後的歷史事件、軟件發布和漏洞修復；還額外添加了一個章節敘述比特幣開發的現狀。文章後附的時間線為每一個事件提供了額外的細節。
對於這裡的大部分事件，我都不是親歷者。所以這份時間線的一大部分引自John Newbery 的一次名為“比特幣開發的歷史與哲學” 的演講。本文的標題也寫得很清楚了，本文沒有，也做不到包含每一個重要事件。歷史總在不斷變化，如果你認為我遺漏了什麼事件，或想提議我作一些修改，請在開源項目bitcoin-development-history 中提交一個issue，這也是我用來附加更多時間線的辦法。
中本聰仍在的時候
這份時間線的起點是2007 年早期。中本聰開始開發比特幣。這個點對點的電子現金系統沒有受信任的地方。整個系統完全由用戶運行的軟件來控制。
早期，有貢獻者加入了中本聰的工作。除了軟件的開發，這些新來的貢獻者還為軟件添加了Linux 和maxOS 操作系統的支持。到了2010 年夏天，中本聰給軟件做了一些關鍵的修改。比如，引入了“檢查點” 作為一項安全措施，來對抗傳播低難度鏈的攻擊。使用了這些檢查點的節點會拒絕那些特定高度與特定區塊不符的鏈。檢查點是由中本聰獨自硬編碼的，理論上來說，這讓中本聰可以自己決定整個網絡要跟隨哪條鏈。
加入檢查點的幾天后，中本聰在版本v0.3.3 的軟件中放出了第一個共識機制變更。中本聰敦促用戶升級。在接下來一個月裡，多個小版本更新陸續放出。其中一個修復了一個致命的溢出漏洞。這個漏洞被利用來創造了兩個高價值的UTXO。中本聰建議礦工們重組包含了惡意交易的區塊。
一周以後，中本聰加入了一個警報系統，來提醒節點運營者網絡中出現的類似bug 和問題。這個警報系統有一個安全模式。這個安全模式一旦觸發，就會禁用整個網絡的所有關於貨幣處理的RPC 方法。只有中本聰能夠用一個私鑰簽名來創建有效的網絡警報。一些用戶開始提出質疑：如果其他人，比如某個政府，拿到了這個私鑰，那網絡會變成什麼樣呢？
這個時候，中本聰對比特幣網絡有太大的權力。但大家主要擔心的不是中本聰會變壞、會摧毀整個網絡，而是一個去中心化的網絡中不應該存在一個單點故障。
到了2010 年10 月，中本聰在bitcointalk 論壇上發布了他的最後一個帖子，宣布移除這個安全模式。中本聰在他最後留下的電子郵件之一里面寫道：“我準備到別的地方去了。有了Gavin 和大家，這個項目會得到很好的維護。” 一些人主張，中本聰離開比特幣世界，是他最偉大的貢獻之一。
中本聰離開之後
幾乎同一時間，整個開發流程從SVN 轉移到了GitHub 上。 BlueMatt、sipa、laanwj 和gmaxwell 加入了這個項目。在2011 年中，BIP（比特幣升級提議）流程應運而生。在2011 年的最後一個季度和2012 年的第一個月，社區討論了允許交易的接收者指定花費條件的多個提案。由此，P2SH 交易引入了比特幣。
在2012 年末，比特幣基金會宣告成立。比特幣基金會（Bitcoin Foundation）模仿的是Linux 基金會。在公告帖子下面，一些人留言表示擔心開發會變得中心化。
Bitcoin v0.8.0 在2013 年春天發布。兩週以後，一場意料之外的硬分叉在網絡中升級了和沒升級的節點間爆發。硬分叉很快就被解決了，礦工們都把挖礦算力切換到了對已升級和未升級節點都有效的鏈上。
在2013 年末，Bitcoin 軟件更名為Bitcoin Core。在接下來幾年裡，包括Chaincode 和Blockstream 在內的公司成立。後來，MIT Digital Currency Initiative 加入了Chaincode 和Blockstream，為開發比特幣的開發者和研究者提供報酬。在2015 年二月，Joseph Poon 和Tadgw Dryja 放出了閃電網絡白皮書的第一份草稿。
第二年，Luke Dashjr 通過BIP 2 修訂了BIP 流程；Bitcoin Core 放出了v0.13.0，加入了SegWit 作為軟分叉。在2016 年11 月，警報系統完全棄用。到了2017 年8 月，SegWit 在比特幣網絡上激活。 2019 年，又一家公司Square Crypto 開始資助比特幣開發。在2019 年5 月，Pieter Wuille 提出了BIP taproot。
比特幣開發的現狀
在過去幾年中，比特幣的開發文化日益去中心化、目標明確而且嚴格。現在Bitcoin Core 代碼庫有6 名維護者，分佈在三個國家。只有他們能夠合併由貢獻者提出的代碼更改。不過，在內容合併之前，更改的內容還需經過一個審議流程，這個流程也變得嚴格得多。
舉個例子，在比特幣早期，有個與P2SH 相競爭的提議，叫做“OP_EVAL”。有個實現了OP_EVAL 的pull request（“合併請求”）在2011 年底被合併到了代碼庫中。即便是這樣對共識有重大變更的代碼，它也只有一個審核人。 Russell O’Connor 開了一個issue 批評了這個實現的一部分，並主張這麼大的、對共識極為關鍵的變更應該得到更多的審核和測試。
這件事推動瞭如何通過更多的測試和審核來實現更高質量的代碼的持續討論。到了今天，每一個合併請求都有多個開發者來審核。如果某個改變觸及到了對安全性甚至共識的關鍵部分，審核的流程還需要通過更多的審核員審核，需要大量的測試，通常會花費幾個月的時間。活躍的Bitcoin Core 貢獻者John Newbery 告訴我，“只需一個審核人員首肯就能合併影響共識的代碼的事情，已經一去不復返”。
人們也投入了很多精力到自動化的測試中，比如，有C++ 語言編寫的單元測試和Python 語言編寫的功能性測試。每一個不簡單的變更都要相應更新現有的測試或者在框架中加入新的測試。在單元測試和功能測試以外，還要在Bitcoin Core 上做模糊測試，以及建立基準測試框架來度量代碼的性能。舉個例子，bitcoinperf.com 網絡提供了Grafana 和codespeed 接口來可視化週期性的基準測試的結果。
多年努力下來，Bitcoin Core 軟件已經形成了一個清晰的發布流程。 Bitcoin Core 的大版本每6 個月發布一次。發行計劃包括一個翻譯流程，一個特性凍結流程，還通常有多個候選版本。近期Cory Fields 和Carl Dong 還致力於提高Bitcoin Core 構建過程的安全性，使用確定性和可引導的構建包。這個新的構建系統可能還沒準備好支持即將在今年秋天發布的Bitcoin Core v0.19.0，但未來可以提供更好的構建過程安全性。
結論
十年間，比特幣的開發文化滄海桑田，從圍繞中本聰的高度中心化，變為圍繞幾千名GitHub 貢獻者（2018 年數據）的去中心化。顯然，代碼審核、代碼質量和安全性的高標準都是有必要的。這些標準得到了遵循和持之以恆的提高。
我認為，要完全理解比特幣開發現狀背後的哲學，了解這些歷史事件是必不可少的。所以我做了一個把更多事件串起來的時間線。
若有進一步的研究需求，建議閱讀 Alex B. 寫的 The Tao Of Bitcoin Development（比特幣開發之道）（中文譯本）、Eric Lombrozo 寫的 The Bitcoin Core Merge Process（Bitcoin Core 代碼合併流程） 以及 Jameson Lopp 的大作 Who Controls Bitcoin Core？ （誰控制著Bitcoin Core？）。
致謝
感謝John Newbery 幫助我梳理並審核這篇文章。他在自己的演講 History and Philosophy of Bitcoin Development（比特幣開發的歷史和哲學）中做了很多歷史考證工作，該演講也是我這篇文章的基礎。此外，我非常感激Chaincode Labs，他邀請我參加他們的2019 夏令營（Summer Residency），在那裡我遇見了很多有意思的人，學到了很多東西，也正是在那裡，我開始著手整理時間線和撰寫這篇文章。
（未完）
（文內有許多超鏈接，可點擊左下”閱讀原文“ 從EthFans 網站上獲取）
原文鏈接:
https://b10c.me/blog/004-the-incomplete-history-of-bitcoin-development/
作者: 0xB10C
翻譯: 阿劍
