来源：加密谷Live
谁在控制Bitcoin Core（比特币核心）的GitHub信息库，这个问题经常被人提出。但这本身就是一个转移视线的提法，源于威权主义的观点。显然，这种提法不适用于BTC。
谁在控制Bitcoin Core（比特币核心）的GitHub信息库，这个问题经常被人提出。但这本身就是一个转移视线的提法，源于威权主义的观点。显然，这种提法不适用于BTC。
本文旨在揭示Bitcoin Core如何运作，以及在更高层次上BTP本身如何发展。
本文作者为Bitcoin Core开发者，由加密谷独家编译
Bitcoin Core的历史
Bitcoin Core是开发BTP的焦点，而不是一个指挥和控制点。如果它因为任何原因不复存在，一个新的焦点就会出现——它所基于的技术通信平台(目前是GitHub存储库) 是一个方便而非定义/项目完整性的问题。事实上，我们已经目睹BTC发展重心改变了平台甚至名字!
2009年初，BTC项目的源代码只是托管在SourceForge上的一个.rar文件。早期的开发人员实际上会通过E-mail与Satoshi交换代码补丁。
2009年10月30日，Sirius (Martti Malmi)在SourceForge上为BTC项目创建了一个subversion存储库。
2011年，BTC项目从SourceForge迁移到了GitHub。
2014年，BTC项目更名为Bitcoin Core。
不轻信任何人
虽然一些少数有组织的GitHub”维护者”帐户能够将代码合并到主分支中，但这更像是一种”清洁工”的职位，而非掌权者。
Bitcoin Core遵循最小特权原则，即如果被滥用，任何赋予个人的权力都很容易被颠覆。
Peter Todd推文: “Core对于重要的列表是公开透明的，可以签署合并提交的PGP密钥。”
这里要学到的教训是：不要轻易相信GitHub！即便Bitcoin Core也不知道可以更改回购的人员的完整列表，因为这可能扩展到数十名GitHub员工。”
从反抗者的角度来看，GitHub是不可信任的。任何GitHub员工都可以使用他们的管理权限将代码注入存储库，而无需维护人员的同意。但GitHub攻击者不太可能破坏Bitcoin Core维护者的PGP密钥。
Bitcoin Core不是基于GitHub帐户代码的完整性，而是具有持续集成系统，该系统执行必须对每个合并提交签名的可信PGP密钥进行检查。虽然这些密钥与已知身份相绑定，但仍然无法确保万无一失。密钥可能会被泄露，除非原始密钥持有者通知其他维护者，否则我们将无从得知。 因此，提交密钥也不能提供完美的安全性，它们只会使攻击者更难以注入任意代码。
开启王国的钥匙
在撰写本文时，这些是可信赖的PGP指纹：
71A3B16735405025D447E8F274810B012346C9A6133EAC179436F14A5CF1B794860FEB804E66932032EE5C4C3FA15CCADB46ABE529D4BCB6416F53ECB8B3F1C0E58C15DB6A81D30C3648A882F4316B9BCA03882CB1FC067B5D3ACFE4D300116E1C875A3D
这些密钥注册给了:
Wladimir J. van der Laan <laanwj@protonmail.com>
Pieter Wuille <pieter.wuille@gmail.com>
Jonas Schnelli <dev@jonasschnelli.ch>
Marco Falke <marco.falke@tum.de>
Samuel Dobson <dobsonsa68@gmail.com>
这是否意味着我们可以完全相信这五个人？并不是。钥匙不是身份证明 ，可能落入其他人的手中。如果运行verify-commits python脚本，你能得到什么保证呢？
python3 contrib/verify-commits/verify-commits.py Using 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脚本是一个完整性检查，任何开发人员都可以在他们的机器上运行。执行后，它会在自2015年12月提交82bcf405之后的每个合并提交中检查PGP签名。在编写时已经超过3,400次合并。
如果脚本成功完成，它告诉我们，自那时起已经更改的每一行代码都已通过Bitcoin Core开发过程，并被具有维护者密钥的人进行了”签名”。虽然这无法完全保证没有人注入恶意代码，但会大大减少攻击面。
什么是”维护者”，以及他们是如何实现这一角色的，这点我们稍后会深入研究。
多层防御
Bitcoin Core代码的完整性不能仅仅依赖于少数密钥，这就是为什么存在大量其他检查的原因。
有许多安全层来提供深度防御：
Pull Request安全性
任何人都可以通过在Bitcoin/Bitcoin上打开针对主分支的Pull Request (简称PR)，来自由地提出代码更改，以改进软件。
开发人员审核PR以确保它们无害。任何人都可以自由地审查PR并提供反馈。在为Bitcoin Core做出贡献时，没有门槛或入门测试。如果没有人对一个PR提出合理的反对意见，那么维护者就会进行合并。
Core维护者设置pre-push hook，以确保它们不会将未签名的提交推送到存储库中。
合并提交可以选择通过OpenTimestamps加上安全时间保障。
Travis Continuous Integration系统会定期运行此脚本以检查git tree（历史）的完整性，并验证主分支中的所有提交是否都由可信的PGP密钥进行签名。
任何想要运行此脚本以验证所有合并提交的PGP签名的人都可以追溯到2015年12月。
发布安全性
Gitian确定性构建系统由多个开发人员独立运行，目标是创建相同的二进制文件。如果有人设法创建与其他开发人员不匹配的构建，即表明引入了非确定性，则最终版本不会发生。如果存在非确定性，开发人员会追踪出错的地方，修复它，并构建另一个候选版本。一旦确定性构建成功，那么开发人员就会对生成的二进制文件进行签名，从而保证文件和工具链不被篡改并且使用相同的源代码。此方法将构建和分发过程作为单点故障删除。任何具有技术技能的人都可以运行自己的构建系统。
一旦Gitian构建成功完成，并由构建者签署，Bitcoin Core维护者便会签署一条包含每个SHA256哈希值的消息。如果你决定运行预构建的二进制文件，则可以在下载后检查其哈希值，然后使用哈希值验证签名版本消息的真实性。
以上所有内容都是开放源代码，任何有技能和意愿的人都可以审核。
最后，即使完成上述所有质量检查和完整性检查，提交到Bitcoin Core，并最终进入版本的代码也不会被任何中心化的实体部署到节点网络上。相反，每个节点运行者必须有意识地决定是否更新他们运行的代码。Bitcoin Core刻意没有加入自动更新功能，因为它可能用于使用户运行他们没有明确选择的代码。
尽管Bitcoin Core项目实施了所有技术安全措施，但它们也并非完美。理论上，任何代码都有可能遭到损害。Bitcoin Core代码完整性的最后一道防线与任何其他开源项目相同：时刻保持警惕。有越多的人盯着Bitcoin Core代码，进入发布版本的恶意或缺陷代码就越少。
代码覆盖范围
Bitcoin Core有许多测试代码。有一个针对每个PR运行的集成测试套件和一个每晚在主服务器上运行的扩展测试套件。
可以通过以下方式自行检查测试的代码覆盖率：
1. 克隆Bitcoin Core的GitHub存储库；
2. 从源代码安装构建所需的依赖项；
3. 运行这些命令；
4. 在./total_coverage/index.html上查看报告；
或者， 可以查看由Marco Falke主持的代码覆盖率报告。如下图：
代码覆盖率报告
代码覆盖率越高，意味着预期运行的确定性越高。
当涉及到共识关键软件时，测试非常重要。 对于特别复杂的更改，开发人员有时需要进行艰苦的变异测试。也就是说，他们通过故意破坏代码来查看测试是否会按照预期一样失败。
Greg Maxwell在讨论0.15版本时，对这个过程给出了一些见解：
“测试是对软件的测试。要测试，你必须破解软件本身。”
自由市场竞争
BitMEX曾撰写了一篇关于BTC实现路径生态系统的精彩文章。目前有十几种不同的BTC实现方式，甚至会有更多的”竞争网络”实现。这是开源的自由，任何对Bitcoin Core项目不满意的人，都可以自由地开启他们自己的项目。他们可以从头开始，也可以分叉Core软件。
在撰写本文时，有96％的BTC节点正在运行某种版本的Bitcoin Core。为什么会出现这种情况？
如果切换到另一个软件实现路径所需的努力最小，那么是否意味着Bitcoin Core在节点网络上具有近乎垄断的地位？ 毕竟，许多其他实现方法提供了与Bitcoin Core兼容或高度相似的RPC API。
我认为，这是Bitcoin Core成为开发焦点的结果。它拥有更多开发人才和时间作为支持，这意味着，Bitcoin Core项目生成的代码往往拥有最好的性能、稳健和安全。
在资金管理方面，节点运营商不会想运行次好的软件。同时，鉴于这是一个共识软件，BTP不具有（也不能有），一个正式的规范，因为没有人有权威制订。因此，用焦点开发人员的实现方式或多或少都更安全。
从这个意义上说，开发焦点的代码是最接近现有规范的代码。
谁是Core的开发人员?
对于不熟悉Bitcoin Core开发过程的人，从外部看这个项目，可能会认为Core是一个单一的实体。实际情况远非如此！
核心贡献者之间经常存在分歧，即使是最多产的贡献者也编写了大量从未合并到项目中的代码。如果阅读相关指南，你可能会注意到，它们相当松散——这个过程可以用”粗略的共识”来描述。
维护人员会考虑：一个补丁是否符合项目的一般原则？是否符合纳入的最低标准？进而对贡献者的普遍共识进行判断。
谁是BTC Core的维护者？他们是在一段时间内做出高质量的代码、在项目中累积了足够的社会资本的贡献者。
当现有的维护者们认为，某位贡献者是在某一领域能力表现突出、可靠、积极的人选时，他们可以授予该人员GitHub帐户提交访问权。
首席维护者的角色负责监督和协调项目的方方面面。它是多年来自愿流传下来的：
Satoshi Nakamoto: 1/3/09 – 2/23/11
Gavin Andresen: 2/23/11 – 4/7/14
Wladimir van der Laan: 4/7/14—present
作为一个Bitcoin Core维护者通常被称为”清洁工”，因为维护者实际上没有权力做出违背贡献者或用户共识的决定。然而，由于整个生态系统被外界过分关注，这个角色的工作可能相当繁重。
例如， Gregory Maxwell (格雷戈里 · 麦克斯韦尔) 在2017年出于个人原因放弃了他的维护者角色，很可能是因为他在扩容讨论期间所承受的公众压力。
Wladimir写了一篇作为核心维护者的压力的文章，其中解释了为什么移除Gavin的提交访问，这让很多人感到不安。
同样地，当Jeff Garzik被从GitHub组织中移除时，他和其他人也都感到不满，但他已经两年没有为Core做贡献了。保留他GitHub帐户对储存库的访问权限，不仅对项目没有任何好处，反而会构成安全风险，并且违反了Wladimir在他的文章中提到的最小特权原则。
其他人可能会关注Core，认为它是一个技术统治或象牙塔，让新人很难加入。但如果你和贡献者交谈，就会发现事实并非如此。虽然多年来只有十几个人拥有提交访问权限，但已有数百名开发人员做出了贡献。我自己也做了一些小贡献。虽然我不认为自己是一个”核心” 开发人员，但严格来说，我也是一名Core开发者。没有人能阻止你做出贡献!
Matt Corallo 推文: “2011年，作为一名不懂标记的高中生，开发者社区（特别是像Greg Maxwell, pwuille等人）与我合作，让我糟糕的补丁变得值得合并，并创造了一个伟大的学习环境。”
John Newbery 推文: ” 2016年，@ TheBlueMatt在@ChaincodeLabs组织了一次访问。我一直在阅读有关BTC的所有内容，我可以放手尝试，但还是不敢提交PR。Matt，Alex和Suhas非常慷慨地花时间教我们关于BTC的一切，以及如何做贡献。”
Jeff Rade推文: “我开始对@bitcoincoreorg进行小型提交，并且对@MarcoFalke @pwuille @orionwl @LukeDashjr和@jfnewbery加入我的PR深深感动，这真是一个热情的项目!”
人们最难以理解的事情之一似乎是，BTC发展的焦点并不仅仅是Bitcoin Core GitHub账户定义的结构。虽然Bitcoin Core有一些结构 (它使用中心化的通信渠道来进行协调)，但项目本身不受任何参与者的控制——即使是那些升级了GitHub存储库特权的参与者也不行。
虽然从技术上讲，维护人员组织内部可能会发生”政变”，并有可能劫持GitHub存储库，审查持不同意见的开发人员，甚至可能抢夺”Bitcoin Core”的品牌名称，但结果是Bitcoin Core将不再是开发的重点。反对维护者行为的开发人员只需将代码分叉，并将工作转移到Bitcoin Core维护者没有管理权限的另一个存储库。
即使没有”政变”，如果一个有争议的变更以某种方式进入Core，部分开发人员会将软件分叉，删除这个变更，并将其提供给用户使用。你可能会说，这正是Amaury Sechet分叉Bitcoin Core，并删除隔离见证，创建比特币ABC时所发生的事情。或者，如果Core拒绝一些人想要的提议的变更，开发人员可以分叉，再添加这些变更。这种情况发生过很多次，例如：
Mike Hearn用forked Core创建了Bitcoin XT
Andrew Stone创立了Core，创建了Bitcoin Unlimited
Jeff Garzik用fork Core创建了BTC1
分叉代码很容易。转移BTC发展的焦点却很困难的——你必须说服贡献者，他们最好把时间花在另一个项目上。
James Lopp推文：”我不对任何人、任何比特币开发团队效忠。我的意图是运行最能保护我财务主权的代码。”
很难说服公众。用户不会盲目地追随Bitcoin Core的变化，这是一种自我强化的信念，因为如果用户不参与共识过程，并意识到自己的选择，他们就会把部分权力拱手让给开发者。
然而，用户在2017年的UASF (User Activated Soft Fork) 运动中，实行了他们的权利。一位化名shaolinfry的BTC开发者提出了BIP 148，这个提案将迫使矿工在8月1日左右激活隔离见证。
然而，由于BIP 148争议太大，无法被Bitcoin Core采纳，所以shaolinfry将Core进行了分叉，并提供了”Bitcoin UASF”软件。这个软件实现获得了不小的吸引力，并且创造了充分的压力来说服矿工在BIP 148截止日期之前采用BIP 91来激活fork。
在我看来，最好的Bitcoin Core贡献者是那些充分实行主权的人。例如John Newbery，尽管他没有编写包含这个特定共识错误的代码，但是他认为自己有责任仔细地检查来阻止它被合并，并且在编写测试时发现这个错误的代码。
John Newbery推文: ” 我为CVE-2018-17144的错误全权负责。错误的代码被合并是不对的。由于没有彻底地审查共识变更，整个社区搞砸了它，开发人员需要注意！这是大家的责任。”
我们都是 Satoshi (中本聪)！
为Bitcoin Core做贡献
虽然有足够的资源可以帮助有抱负的开发人员，但为Core做贡献仍旧让人感到畏惧。你可以从Jimmy Song写的指导说明”A Gentle Introduction to Bitcoin Core Development”入手。
Core开发人员Eric Lombrozo还撰写了一篇文章”The Bitcoin Core Merge Process”，了解如何在Core存储库中进行更改。
此外，Alex B.撰写了一篇关于BTC开发理念的优秀文章”The Tao of Bitcoin Development”，任何想要成为贡献者的人都可以通过阅读它来节省大量时间。
具体的示例可能会有所帮助。在写这篇文章时，我尝试在我的机器上运行verify-commits.py脚本，以便审核GitHub提交历史记录的完整性，但遇到了困难。
为了便于未来的开发人员规避这些问题，我打开了一个PR来改进文档。从PR历史中可以看出，有4位不同的开发人员提出了如何改进PR的建议。这包括使用不同的wiki标记到简化的bash命令，以及可以在verify-commits.py脚本中使用的新参数。我认为所有的建议都很合理，所以我将它们合并到我的代码中，并为我的PR推送了更新版本。在那时，参与审查的开发人员承认可他们发现PR，维护者Marco Falke将其标记为包含在0.18版本中。经过几天的努力，开发人员没有反对意见，代码被维护者Samuel Dobson合并到了Core中。
总结：没有人能够掌控BTC
正如饱受争议的那样，把BTC理解为一个系统是不可能的。对BTP 的定义 (控制)， 就如同对语言的定义。语言是自然产生的，对词汇含义的共识是有机的，而不是由字典决定的。就像字典描述一种语言的现象而不是定义它，BTC的实现方式也用代码描述了BTC的语言。没有人被迫同意字典中给出的定义，同样，也没有人被迫运行BTC实现方式或认同这一过程中的代码。
语言不受民主支配，BTC也不受民主管理。虽然你可能会听到人们提到矿工、节点、开发人员或用户”投票”，但是，没有任何一种机制能够让多数人迫使持不同意见的少数人接受他们不同意的变更。简言之，BTC是无政府状态——没有统治者，但也不是没有规则。规则由网络上的各个参与者定义和执行。
对BTP本身的更改通常是通过BTC改进提案流程进行的，即使这只是一个推荐的最佳实践，也不能强迫任何人遵循它。它只是一种更正式的方式，试图通过同行审查和建立共识的过程来指导变革。
BTC抗脆弱性的一个重要方面——如果只有一个单一的控制点，那么它也是一个单一的故障点，会被强大实体所利用。最终，每个节点运行者通过确保网络上没有其他人违反它们达成一致的规则来管理自己。这种安全模型是BTC自下而上治理的基础。
没有人掌控BTC。没有人掌控BTC开发的焦点。