誰在控制Bitcoin Core(比特幣核心)的GitHub信息庫，這個(gè)問題經(jīng)常被人提出。但這本身就是一個(gè)轉(zhuǎn)移視線的提法，源于威權(quán)主義的觀點(diǎn)。顯然，這
誰在控制Bitcoin Core(比特幣核心)的GitHub信息庫，這個(gè)問題經(jīng)常被人提出。但這本身就是一個(gè)轉(zhuǎn)移視線的提法，源于威權(quán)主義的觀點(diǎn)。顯然，這種提法不適用于BTC。
本文旨在揭示Bitcoin Core如何運(yùn)作，以及在更高層次上BTP本身如何發(fā)展。
Bitcoin Core的歷史
Bitcoin Core是開發(fā)BTP的焦點(diǎn)，而不是一個(gè)指揮和控制點(diǎn)。如果它因?yàn)槿魏卧虿粡?fù)存在，一個(gè)新的焦點(diǎn)就會(huì)出現(xiàn)——它所基于的技術(shù)通信平臺(tái)(目前是GitHub存儲(chǔ)庫) 是一個(gè)方便而非定義/項(xiàng)目完整性的問題。事實(shí)上，我們已經(jīng)目睹BTC發(fā)展重心改變了平臺(tái)甚至名字!
2009年初，BTC項(xiàng)目的源代碼只是托管在SourceForge上的一個(gè).rar文件。早期的開發(fā)人員實(shí)際上會(huì)通過E-mail與Satoshi交換代碼補(bǔ)丁。
2009年10月30日，Sirius (Martti Malmi)在SourceForge上為BTC項(xiàng)目創(chuàng)建了一個(gè)subversion存儲(chǔ)庫。
2011年，BTC項(xiàng)目從SourceForge遷移到了GitHub。
2014年，BTC項(xiàng)目更名為Bitcoin Core。
不輕信任何人
雖然一些少數(shù)有組織的GitHub“維護(hù)者”帳戶能夠?qū)⒋a合并到主分支中，但這更像是一種“清潔工”的職位，而非掌權(quán)者。
Bitcoin Core遵循最小特權(quán)原則，即如果被濫用，任何賦予個(gè)人的權(quán)力都很容易被顛覆。
Peter Todd推文: “Core對(duì)于重要的列表是公開透明的，可以簽署合并提交的PGP密鑰。”
這里要學(xué)到的教訓(xùn)是：不要輕易相信GitHub!即便Bitcoin Core也不知道可以更改回購的人員的完整列表，因?yàn)檫@可能擴(kuò)展到數(shù)十名GitHub員工。”
從反抗者的角度來看，GitHub是不可信任的。任何GitHub員工都可以使用他們的管理權(quán)限將代碼注入存儲(chǔ)庫，而無需維護(hù)人員的同意。但GitHub攻擊者不太可能破壞Bitcoin Core維護(hù)者的PGP密鑰。
Bitcoin Core不是基于GitHub帳戶代碼的完整性，而是具有持續(xù)集成系統(tǒng)，該系統(tǒng)執(zhí)行必須對(duì)每個(gè)合并提交簽名的可信PGP密鑰進(jìn)行檢查。雖然這些密鑰與已知身份相綁定，但仍然無法確保萬無一失。密鑰可能會(huì)被泄露，除非原始密鑰持有者通知其他維護(hù)者，否則我們將無從得知。因此，提交密鑰也不能提供完美的安全性，它們只會(huì)使攻擊者更難以注入任意代碼。
開啟王國(guó)的鑰匙
在撰寫本文時(shí)，這些是可信賴的PGP指紋：
71A3B16735405025D447E8F274810B012346C9A6133EAC179436F14A5CF1B794860FEB804E66932032EE5C4C3FA15CCADB46ABE529D4BCB6416F53ECB8B3F1C0E58C15DB6A81D30C3648A882F4316B9BCA03882CB1FC067B5D3ACFE4D300116E1C875A3D
這些密鑰注冊(cè)給了:
Wladimir J. van der Laan
Pieter Wuille
Jonas Schnelli
Marco Falke
Samuel Dobson
這是否意味著我們可以完全相信這五個(gè)人?并不是。鑰匙不是身份證明 ，可能落入其他人的手中。如果運(yùn)行verify-commits python腳本，你能得到什么保證呢?
python3 contrib/verify-commits/verify-commits.pyUsing verify-commits data from bitcoin/contrib/verify-commitsAll Tree-SHA512s matched up to 309bf16257b2395ce502017be627186b749ee749There is a valid path from “HEAD” to 82bcf405f6db1d55b684a1f63a4aabad376cdad7 where all commits are signed!
Verify-commits腳本是一個(gè)完整性檢查，任何開發(fā)人員都可以在他們的機(jī)器上運(yùn)行。執(zhí)行后，它會(huì)在自2015年12月提交82bcf405之后的每個(gè)合并提交中檢查PGP簽名。在編寫時(shí)已經(jīng)超過3,400次合并。
如果腳本成功完成，它告訴我們，自那時(shí)起已經(jīng)更改的每一行代碼都已通過Bitcoin Core開發(fā)過程，并被具有維護(hù)者密鑰的人進(jìn)行了“簽名”。雖然這無法完全保證沒有人注入惡意代碼，但會(huì)大大減少攻擊面。
什么是“維護(hù)者”，以及他們是如何實(shí)現(xiàn)這一角色的，這點(diǎn)我們稍后會(huì)深入研究。
多層防御
Bitcoin Core代碼的完整性不能僅僅依賴于少數(shù)密鑰，這就是為什么存在大量其他檢查的原因。
有許多安全層來提供深度防御：
Pull Request安全性
任何人都可以通過在Bitcoin/Bitcoin上打開針對(duì)主分支的Pull Request (簡(jiǎn)稱PR)，來自由地提出代碼更改，以改進(jìn)軟件。
開發(fā)人員審核PR以確保它們無害。任何人都可以自由地審查PR并提供反饋。在為Bitcoin Core做出貢獻(xiàn)時(shí)，沒有門檻或入門測(cè)試。如果沒有人對(duì)一個(gè)PR提出合理的反對(duì)意見，那么維護(hù)者就會(huì)進(jìn)行合并。
Core維護(hù)者設(shè)置pre-push hook，以確保它們不會(huì)將未簽名的提交推送到存儲(chǔ)庫中。
合并提交可以選擇通過OpenTimestamps加上安全時(shí)間保障。
Travis Continuous Integration系統(tǒng)會(huì)定期運(yùn)行此腳本以檢查git tree(歷史)的完整性，并驗(yàn)證主分支中的所有提交是否都由可信的PGP密鑰進(jìn)行簽名。
任何想要運(yùn)行此腳本以驗(yàn)證所有合并提交的PGP簽名的人都可以追溯到2015年12月。
發(fā)布安全性
Gitian確定性構(gòu)建系統(tǒng)由多個(gè)開發(fā)人員獨(dú)立運(yùn)行，目標(biāo)是創(chuàng)建相同的二進(jìn)制文件。如果有人設(shè)法創(chuàng)建與其他開發(fā)人員不匹配的構(gòu)建，即表明引入了非確定性，則最終版本不會(huì)發(fā)生。如果存在非確定性，開發(fā)人員會(huì)追蹤出錯(cuò)的地方，修復(fù)它，并構(gòu)建另一個(gè)候選版本。
一旦確定性構(gòu)建成功，那么開發(fā)人員就會(huì)對(duì)生成的二進(jìn)制文件進(jìn)行簽名，從而保證文件和工具鏈不被篡改并且使用相同的源代碼。此方法將構(gòu)建和分發(fā)過程作為單點(diǎn)故障刪除。任何具有技術(shù)技能的人都可以運(yùn)行自己的構(gòu)建系統(tǒng)。
一旦Gitian構(gòu)建成功完成，并由構(gòu)建者簽署，Bitcoin Core維護(hù)者便會(huì)簽署一條包含每個(gè)SHA256哈希值的消息。如果你決定運(yùn)行預(yù)構(gòu)建的二進(jìn)制文件，則可以在下載后檢查其哈希值，然后使用哈希值驗(yàn)證簽名版本消息的真實(shí)性。
以上所有內(nèi)容都是開放源代碼，任何有技能和意愿的人都可以審核。
最后，即使完成上述所有質(zhì)量檢查和完整性檢查，提交到Bitcoin Core，并最終進(jìn)入版本的代碼也不會(huì)被任何中心化的實(shí)體部署到節(jié)點(diǎn)網(wǎng)絡(luò)上。相反，每個(gè)節(jié)點(diǎn)運(yùn)行者必須有意識(shí)地決定是否更新他們運(yùn)行的代碼。Bitcoin Core刻意沒有加入自動(dòng)更新功能，因?yàn)樗赡苡糜谑褂脩暨\(yùn)行他們沒有明確選擇的代碼。
盡管Bitcoin Core項(xiàng)目實(shí)施了所有技術(shù)安全措施，但它們也并非完美。理論上，任何代碼都有可能遭到損害。Bitcoin Core代碼完整性的最后一道防線與任何其他開源項(xiàng)目相同：時(shí)刻保持警惕。有越多的人盯著Bitcoin Core代碼，進(jìn)入發(fā)布版本的惡意或缺陷代碼就越少。
代碼覆蓋范圍
Bitcoin Core有許多測(cè)試代碼。有一個(gè)針對(duì)每個(gè)PR運(yùn)行的集成測(cè)試套件和一個(gè)每晚在主服務(wù)器上運(yùn)行的擴(kuò)展測(cè)試套件。
可以通過以下方式自行檢查測(cè)試的代碼覆蓋率：
1. 克隆Bitcoin Core的GitHub存儲(chǔ)庫;
2. 從源代碼安裝構(gòu)建所需的依賴項(xiàng);
3. 運(yùn)行這些命令;
4. 在./total_coverage/index.html上查看報(bào)告;
或者， 可以查看由Marco Falke主持的代碼覆蓋率報(bào)告。如下圖：
代碼覆蓋率報(bào)告
代碼覆蓋率越高，意味著預(yù)期運(yùn)行的確定性越高。
當(dāng)涉及到共識(shí)關(guān)鍵軟件時(shí)，測(cè)試非常重要。對(duì)于特別復(fù)雜的更改，開發(fā)人員有時(shí)需要進(jìn)行艱苦的變異測(cè)試。也就是說，他們通過故意破壞代碼來查看測(cè)試是否會(huì)按照預(yù)期一樣失敗。
Greg Maxwell在討論0.15版本時(shí)，對(duì)這個(gè)過程給出了一些見解：
“測(cè)試是對(duì)軟件的測(cè)試。要測(cè)試，你必須破解軟件本身。”
自由市場(chǎng)競(jìng)爭(zhēng)
BitMEX曾撰寫了一篇關(guān)于BTC實(shí)現(xiàn)路徑生態(tài)系統(tǒng)的精彩文章。目前有十幾種不同的BTC實(shí)現(xiàn)方式，甚至?xí)懈嗟?ldquo;競(jìng)爭(zhēng)網(wǎng)絡(luò)”實(shí)現(xiàn)。這是開源的自由，任何對(duì)Bitcoin Core項(xiàng)目不滿意的人，都可以自由地開啟他們自己的項(xiàng)目。他們可以從頭開始，也可以分叉Core軟件。
在撰寫本文時(shí)，有96%的BTC節(jié)點(diǎn)正在運(yùn)行某種版本的Bitcoin Core。為什么會(huì)出現(xiàn)這種情況?
如果切換到另一個(gè)軟件實(shí)現(xiàn)路徑所需的努力最小，那么是否意味著Bitcoin Core在節(jié)點(diǎn)網(wǎng)絡(luò)上具有近乎壟斷的地位?畢竟，許多其他實(shí)現(xiàn)方法提供了與Bitcoin Core兼容或高度相似的RPC API。
我認(rèn)為，這是Bitcoin Core成為開發(fā)焦點(diǎn)的結(jié)果。它擁有更多開發(fā)人才和時(shí)間作為支持，這意味著，Bitcoin Core項(xiàng)目生成的代碼往往擁有最好的性能、穩(wěn)健和安全。
在資金管理方面，節(jié)點(diǎn)運(yùn)營(yíng)商不會(huì)想運(yùn)行次好的軟件。同時(shí)，鑒于這是一個(gè)共識(shí)軟件，BTP不具有(也不能有)，一個(gè)正式的規(guī)范，因?yàn)闆]有人有權(quán)威制訂。因此，用焦點(diǎn)開發(fā)人員的實(shí)現(xiàn)方式或多或少都更安全。
從這個(gè)意義上說，開發(fā)焦點(diǎn)的代碼是最接近現(xiàn)有規(guī)范的代碼。
誰是Core的開發(fā)人員?
對(duì)于不熟悉Bitcoin Core開發(fā)過程的人，從外部看這個(gè)項(xiàng)目，可能會(huì)認(rèn)為Core是一個(gè)單一的實(shí)體。實(shí)際情況遠(yuǎn)非如此!
核心貢獻(xiàn)者之間經(jīng)常存在分歧，即使是最多產(chǎn)的貢獻(xiàn)者也編寫了大量從未合并到項(xiàng)目中的代碼。如果閱讀相關(guān)指南，你可能會(huì)注意到，它們相當(dāng)松散——這個(gè)過程可以用“粗略的共識(shí)”來描述。
維護(hù)人員會(huì)考慮：一個(gè)補(bǔ)丁是否符合項(xiàng)目的一般原則?是否符合納入的最低標(biāo)準(zhǔn)?進(jìn)而對(duì)貢獻(xiàn)者的普遍共識(shí)進(jìn)行判斷。
誰是BTC Core的維護(hù)者？他們是在一段時(shí)間內(nèi)做出高質(zhì)量的代碼、在項(xiàng)目中累積了足夠的社會(huì)資本的貢獻(xiàn)者。
當(dāng)現(xiàn)有的維護(hù)者們認(rèn)為，某位貢獻(xiàn)者是在某一領(lǐng)域能力表現(xiàn)突出、可靠、積極的人選時(shí)，他們可以授予該人員GitHub帳戶提交訪問權(quán)。
首席維護(hù)者的角色負(fù)責(zé)監(jiān)督和協(xié)調(diào)項(xiàng)目的方方面面。它是多年來自愿流傳下來的：
Satoshi Nakamoto: 1/3/09 - 2/23/11
Gavin Andresen: 2/23/11 - 4/7/14
Wladimir van der Laan: 4/7/14—present
作為一個(gè)Bitcoin Core維護(hù)者通常被稱為“清潔工”，因?yàn)榫S護(hù)者實(shí)際上沒有權(quán)力做出違背貢獻(xiàn)者或用戶共識(shí)的決定。然而，由于整個(gè)生態(tài)系統(tǒng)被外界過分關(guān)注，這個(gè)角色的工作可能相當(dāng)繁重。
例如， Gregory Maxwell (格雷戈里 · 麥克斯韋爾) 在2017年出于個(gè)人原因放棄了他的維護(hù)者角色，很可能是因?yàn)樗跀U(kuò)容討論期間所承受的公眾壓力。
Wladimir寫了一篇作為核心維護(hù)者的壓力的文章，其中解釋了為什么移除Gavin的提交訪問，這讓很多人感到不安。
同樣地，當(dāng)Jeff Garzik被從GitHub組織中移除時(shí)，他和其他人也都感到不滿，但他已經(jīng)兩年沒有為Core做貢獻(xiàn)了。保留他GitHub帳戶對(duì)儲(chǔ)存庫的訪問權(quán)限，不僅對(duì)項(xiàng)目沒有任何好處，反而會(huì)構(gòu)成安全風(fēng)險(xiǎn)，并且違反了Wladimir在他的文章中提到的最小特權(quán)原則。
其他人可能會(huì)關(guān)注Core，認(rèn)為它是一個(gè)技術(shù)統(tǒng)治或象牙塔，讓新人很難加入。但如果你和貢獻(xiàn)者交談，就會(huì)發(fā)現(xiàn)事實(shí)并非如此。雖然多年來只有十幾個(gè)人擁有提交訪問權(quán)限，但已有數(shù)百名開發(fā)人員做出了貢獻(xiàn)。我自己也做了一些小貢獻(xiàn)。雖然我不認(rèn)為自己是一個(gè)“核心” 開發(fā)人員，但嚴(yán)格來說，我也是一名Core開發(fā)者。沒有人能阻止你做出貢獻(xiàn)!
Matt Corallo 推文: “2011年，作為一名不懂標(biāo)記的高中生，開發(fā)者社區(qū)(特別是像Greg Maxwell, pwuille等人)與我合作，讓我糟糕的補(bǔ)丁變得值得合并，并創(chuàng)造了一個(gè)偉大的學(xué)習(xí)環(huán)境。”
John Newbery 推文: ” 2016年，@ TheBlueMatt在@ChaincodeLabs組織了一次訪問。我一直在閱讀有關(guān)BTC的所有內(nèi)容，我可以放手嘗試，但還是不敢提交PR。Matt，Alex和Suhas非常慷慨地花時(shí)間教我們關(guān)于BTC的一切，以及如何做貢獻(xiàn)。”
Jeff Rade推文:”我開始對(duì)@bitcoincoreorg進(jìn)行小型提交，并且對(duì)@MarcoFalke @pwuille @orionwl @LukeDashjr和@jfnewbery加入我的PR深深感動(dòng)，這真是一個(gè)熱情的項(xiàng)目!”
人們最難以理解的事情之一似乎是，BTC發(fā)展的焦點(diǎn)并不僅僅是Bitcoin Core GitHub賬戶定義的結(jié)構(gòu)。雖然Bitcoin Core有一些結(jié)構(gòu) (它使用中心化的通信渠道來進(jìn)行協(xié)調(diào))，但項(xiàng)目本身不受任何參與者的控制——即使是那些升級(jí)了GitHub存儲(chǔ)庫特權(quán)的參與者也不行。
雖然從技術(shù)上講，維護(hù)人員組織內(nèi)部可能會(huì)發(fā)生“政變”，并有可能劫持GitHub存儲(chǔ)庫，審查持不同意見的開發(fā)人員，甚至可能搶奪“Bitcoin Core”的品牌名稱，但結(jié)果是Bitcoin Core將不再是開發(fā)的重點(diǎn)。反對(duì)維護(hù)者行為的開發(fā)人員只需將代碼分叉，并將工作轉(zhuǎn)移到Bitcoin Core維護(hù)者沒有管理權(quán)限的另一個(gè)存儲(chǔ)庫。
即使沒有“政變”，如果一個(gè)有爭(zhēng)議的變更以某種方式進(jìn)入Core，部分開發(fā)人員會(huì)將軟件分叉，刪除這個(gè)變更，并將其提供給用戶使用。你可能會(huì)說，這正是Amaury Sechet分叉Bitcoin Core，并刪除隔離見證，創(chuàng)建比特幣ABC時(shí)所發(fā)生的事情?；蛘?，如果Core拒絕一些人想要的提議的變更，開發(fā)人員可以分叉，再添加這些變更。這種情況發(fā)生過很多次，例如：
Mike Hearn用forked Core創(chuàng)建了Bitcoin XT
Andrew Stone創(chuàng)立了Core，創(chuàng)建了Bitcoin Unlimited
Jeff Garzik用fork Core創(chuàng)建了BTC1
分叉代碼很容易。轉(zhuǎn)移BTC發(fā)展的焦點(diǎn)卻很困難的——你必須說服貢獻(xiàn)者，他們最好把時(shí)間花在另一個(gè)項(xiàng)目上。
James Lopp推文：”我不對(duì)任何人、任何比特幣開發(fā)團(tuán)隊(duì)效忠。我的意圖是運(yùn)行最能保護(hù)我財(cái)務(wù)主權(quán)的代碼。”
很難說服公眾。用戶不會(huì)盲目地追隨Bitcoin Core的變化，這是一種自我強(qiáng)化的信念，因?yàn)槿绻脩舨粎⑴c共識(shí)過程，并意識(shí)到自己的選擇，他們就會(huì)把部分權(quán)力拱手讓給開發(fā)者。
然而，用戶在2017年的UASF (User Activated Soft Fork) 運(yùn)動(dòng)中，實(shí)行了他們的權(quán)利。一位化名shaolinfry的BTC開發(fā)者提出了BIP 148，這個(gè)提案將迫使礦工在8月1日左右激活隔離見證。
然而，由于BIP 148爭(zhēng)議太大，無法被Bitcoin Core采納，所以shaolinfry將Core進(jìn)行了分叉，并提供了“Bitcoin UASF”軟件。這個(gè)軟件實(shí)現(xiàn)獲得了不小的吸引力，并且創(chuàng)造了充分的壓力來說服礦工在BIP 148截止日期之前采用BIP 91來激活fork。
在我看來，最好的Bitcoin Core貢獻(xiàn)者是那些充分實(shí)行主權(quán)的人。例如John Newbery，盡管他沒有編寫包含這個(gè)特定共識(shí)錯(cuò)誤的代碼，但是他認(rèn)為自己有責(zé)任仔細(xì)地檢查來阻止它被合并，并且在編寫測(cè)試時(shí)發(fā)現(xiàn)這個(gè)錯(cuò)誤的代碼。
John Newbery推文: ” 我為CVE-2018-17144的錯(cuò)誤全權(quán)負(fù)責(zé)。錯(cuò)誤的代碼被合并是不對(duì)的。由于沒有徹底地審查共識(shí)變更，整個(gè)社區(qū)搞砸了它，開發(fā)人員需要注意!這是大家的責(zé)任。”
我們都是 Satoshi (中本聰)!
為Bitcoin Core做貢獻(xiàn)
雖然有足夠的資源可以幫助有抱負(fù)的開發(fā)人員，但為Core做貢獻(xiàn)仍舊讓人感到畏懼。你可以從Jimmy Song寫的指導(dǎo)說明“A Gentle Introduction to Bitcoin Core Development”入手。
Core開發(fā)人員Eric Lombrozo還撰寫了一篇文章“The Bitcoin Core Merge Process”，了解如何在Core存儲(chǔ)庫中進(jìn)行更改。
此外，Alex B.撰寫了一篇關(guān)于BTC開發(fā)理念的優(yōu)秀文章“The Tao of Bitcoin Development”，任何想要成為貢獻(xiàn)者的人都可以通過閱讀它來節(jié)省大量時(shí)間。
具體的示例可能會(huì)有所幫助。在寫這篇文章時(shí)，我嘗試在我的機(jī)器上運(yùn)行verify-commits.py腳本，以便審核GitHub提交歷史記錄的完整性，但遇到了困難。
為了便于未來的開發(fā)人員規(guī)避這些問題，我打開了一個(gè)PR來改進(jìn)文檔。從PR歷史中可以看出，有4位不同的開發(fā)人員提出了如何改進(jìn)PR的建議。這包括使用不同的wiki標(biāo)記到簡(jiǎn)化的bash命令，以及可以在verify-commits.py腳本中使用的新參數(shù)。
我認(rèn)為所有的建議都很合理，所以我將它們合并到我的代碼中，并為我的PR推送了更新版本。在那時(shí)，參與審查的開發(fā)人員承認(rèn)可他們發(fā)現(xiàn)PR，維護(hù)者M(jìn)arco Falke將其標(biāo)記為包含在0.18版本中。經(jīng)過幾天的努力，開發(fā)人員沒有反對(duì)意見，代碼被維護(hù)者Samuel Dobson合并到了Core中。
總結(jié)：沒有人能夠掌控BTC
正如飽受爭(zhēng)議的那樣，把BTC理解為一個(gè)系統(tǒng)是不可能的。對(duì)BTP 的定義 (控制)， 就如同對(duì)語言的定義。語言是自然產(chǎn)生的，對(duì)詞匯含義的共識(shí)是有機(jī)的，而不是由字典決定的。就像字典描述一種語言的現(xiàn)象而不是定義它，BTC的實(shí)現(xiàn)方式也用代碼描述了BTC的語言。沒有人被迫同意字典中給出的定義，同樣，也沒有人被迫運(yùn)行BTC實(shí)現(xiàn)方式或認(rèn)同這一過程中的代碼。
語言不受民主支配，BTC也不受民主管理。雖然你可能會(huì)聽到人們提到礦工、節(jié)點(diǎn)、開發(fā)人員或用戶“投票”，但是，沒有任何一種機(jī)制能夠讓多數(shù)人迫使持不同意見的少數(shù)人接受他們不同意的變更。簡(jiǎn)言之，BTC是無政府狀態(tài)——沒有統(tǒng)治者，但也不是沒有規(guī)則。規(guī)則由網(wǎng)絡(luò)上的各個(gè)參與者定義和執(zhí)行。
對(duì)BTP本身的更改通常是通過BTC改進(jìn)提案流程進(jìn)行的，即使這只是一個(gè)推薦的最佳實(shí)踐，也不能強(qiáng)迫任何人遵循它。它只是一種更正式的方式，試圖通過同行審查和建立共識(shí)的過程來指導(dǎo)變革。
BTC抗脆弱性的一個(gè)重要方面——如果只有一個(gè)單一的控制點(diǎn)，那么它也是一個(gè)單一的故障點(diǎn)，會(huì)被強(qiáng)大實(shí)體所利用。最終，每個(gè)節(jié)點(diǎn)運(yùn)行者通過確保網(wǎng)絡(luò)上沒有其他人違反它們達(dá)成一致的規(guī)則來管理自己。這種安全模型是BTC自下而上治理的基礎(chǔ)。
沒有人掌控BTC。沒有人掌控BTC開發(fā)的焦點(diǎn)。(作者：Jameson Lopp)
-END -
