比特币核心的历史
比特币核心是比特币协议开发的焦点，而非命令与控制点。倘若因为什么原因，这个焦点停止存在了，就会有一个新的焦点冒出来。比特币核心依赖的基础——技术交流平台，是因为便利而存在的，不是因为定义/项目的完整性而存在的。现实中，比特币的开发焦点已经更换了平台，甚至更换了名称！2009年初，比特币项目的源代码只是一个rar压缩包，存在SourceForge服务器上。早期的开发者会用电邮跟中本聪交换代码补丁。2009年10月30日，Sirius在SourceForge网站上创建了一个subversion代码仓库。2011年，比特币项目从SourceForge迁移到GitHub。2014年，比特币项目更名“BitcoinCore”。不相信任何人
GitHub的组织层面上，确实有不多几个“维护人员”的账户，能够将代码合并到“主分支”；然而这种地位不是权力的象征，只是类似“看守”的身份。试想，若是不论张三李四都能把代码合并到主分支，很快就会变成“厨子多了做坏了汤”的结果。比特币核心遵守“最小特权原则”，也就是任何人只要滥用权力，就会被轻易推翻。
从对抗角度来看，GitHub是不能被信任的。GitHub任何员工都可以运用管理特权，将代码注入代码仓库，无需经过维护人员的同意。但是，GitHub的攻击者却几乎不可能损害比特币核心维护人员的PGP密钥BitcoinCore并没有将代码的完整性建立在GitHub账户上，他们有一个连续的集成系统，执行那些受信任的PGP密钥的校验；这些密钥必须签署每一份“合并提交”。这些密钥的确跟身份已知的某些人相关，但依然不能担保情况永远会这样而不变——某个密钥可能会受到损害，我们也不会知道密钥受到损害，除非原始的密钥主人通知了其他的维护人员。如此一来，“提交密钥”也就不提供完美的安全保护，只是让攻击者插入“任意代码”的难度提高了。通向王国的密钥
我写这篇文章的时候，受信任的PGP指纹如下：71A3B16735405025D447E8F274810B012346C9A6133EAC179436F14A5CF1B794860FEB804E66932032EE5C4C3FA15CCADB46ABE529D4BCB6416F53ECB8B3F1C0E58C15DB6A81D30C3648A882F4316B9BCA03882CB1FC067B5D3ACFE4D300116E1C875A3D这些指纹注册到：WladimirJ.vanderLaan<laanwj@protonmail.com>PieterWuille<pieter.wuille@gmail.com>JonasSchnelli<dev@jonasschnelli.ch>MarcoFalke<marco.falke@tum.de>SamuelDobson<dobsonsa68@gmail.com>这是否意味着我们就相信这五个人呢？不太对。密钥不是身份的证明；这些密钥有可能落到别人手中。我要是运行了verify-commits的python脚本，我有什么保证呢？python3contrib/verify-commits/verify-commits.py使用来自bitcoin/contrib/verify-commits的verify-commits数据所有Tree-SHA512s都匹配到309bf16257b2395ce502017be627186b749ee749有一条从“HEAD”到82bcf405f6db1d55b684a1f63a4aabad376cdad7的有效路径，其中所有提交都已签名！verify-commits脚本是一种完整性校验，随便什么开发者都能将其在自家机器上运行。执行的时候，脚本会校验每一份合并提交的PGP签名。从2015年12月第一次提交82bcf405开始，到我写这篇文章为止，共有3,400多份合并提交。如果脚本成功完成，它告诉我们自那时以来已经更改的每一行代码都已通过比特币核心开发过程并由具有维护者密钥的人“签字”。当然，这还不足以百分百确认不会有人插入恶意代码；但这一措施确实能减少大规模攻击的可能性。那么，维护人员又是什么人？他们怎么获得这个身份？我们稍后会深入研究。 多层安全系统
比特币核心代码的完整性不能仅仅依赖于少数加密密钥，这就是为什么存在大量其他检查的原因。这里有许多安全层来提供深度防御：Pull请求安全1、不论什么人都有权提议改动节点，以改进软件。其方法是开启一个针对bitcoin/bitcoin上主分支的“拉取请求”。2、开发者们会评估各个拉取请求，确保这些请求不是有害的。不论是谁，都有权评估各个拉取请求，并提供反馈。只要是为了比特币核心作出贡献，就没有“看门人”或者“入学考试”筛选合格的贡献者。如果某个拉取请求发展到这样一种地步，并没有合理的反对意见反对它合并到主分支，那就会有一个维护人员执行合并。3、Core维护者会设定预push钩，以确保不会有人把未经签字确认的“提交”“推入”代码仓库。4、各项“合并提交”，会通过OpenTimestamps协议，安全地打上时间戳。打戳行为是可选的，不是必要的。5、“Travis持续集成系统”将定期运行这个脚本，以检查gittree的完整性，而且验证所有主分支上的“提交”都已经由某一个受信任的PGP密钥签了名。6、不论是谁，只要想运行，就可以运行这个脚本，以验证从2015年12月开始的一切“合并提交”上的PGP签名。我在写这篇文章的时候，就运行了这个脚本，在我的笔电上25分钟就运行完了。发布安全1、“Gitian确定性构建系统”是一种编译解决方案。这系统由多个开发者独立运行，目标是创建相同的二进制文件。假设某人成功创建了一个不符合其他开发者的构建系统，就表示引入了“非确定性”，于是“最终发行”就不会发生。如果存在非确定性，开发者就会追踪哪里出了问题，修复问题，再构建另外一种发行候选版本。一旦“确定性构建”成功，开发者就会对生成的二进制文件进行签名，确保这些二进制文件和工具链都没有受到损害，而且使用了相同的源。这个办法避免了让构建和分配流程变成一种“单点故障”。任何具有技术的人都可以运行自己的构建系统。操作说明在这里：https://github.com/bitcoin-core/docs/blob/master/gitian-building.md2、一旦Gitian构建成功完成并由构建者签名，就会有一个BitcoinCore的维护者，用每个构建的SHA256哈希值，给一条信息进行PGP签名。如果你决定运行预先构建的二进制文件，就可以先下载，然后验证它的哈希值；然后使用哈希值验证签名版本消息的真实性。这里是操作说明：https://bitcoincore.org/en/download/3、以上这些全都是开源的，可审计的；任何人只要有技术，有意愿，都可以执行。4、最后，即使在进行了以上一切的质量与完整性检查之后，提交到BitcoinCore并最后成功发布的代码依然不会被任何中心化的组织部署到节点网络上。相反，每个节点操作员必须有意识地决定更新他们运行的代码。BitcoinCore故意没有设置自动更新功能，让用户可自行决定需要运行什么版本的代码，否则这个系统就可能被操纵。尽管比特币核心有了一切技术上的安全手段，然而这些手段没有一种是完美的，也全都有理论上被损害的可能性。比特币核心代码完整性的最后一道防线，与任何其他开源项目的最后一道防线是一样的——时刻保持警惕！关注比特币核心代码的眼睛越多，恶意代码或者有缺陷代码，就越难以进入发布阶段。代码覆盖率
BitcoinCore有很多测试代码，其中包括一个完整性测试组件，可以用来测试所有PR；还有一种扩展测试套件，可以每晚在主分支上运行。你可以自行检查各种测试的代码覆盖率，方法是：克隆一个比特币核心GitHub代码仓库；安装所需的从源代码构建的依赖项；运行这些命令；在./total_coverage/index.html查看报告。除此以外，你还可以查看比特币软件维护者MarcoFalke主持的的覆盖率报告，地址是https://drahtbot.github.io/reports/coverage/bitcoin/bitcoin/master/total.coverage/index.html
代码覆盖率水平越高，意味着代码按照预期执行功能的确定性也越高。若想在关键的软件上达成共识，测试就是一件大事。对于某些特别复杂的改动，开发者有时候要进行痛苦的“变异测试”，也就是故意破坏密码，看看各个测试有没有按照预期而失败。比特币开发者GregMaxwell比特币核心0.15发布的时候，专门讨论过这种变异测试：“测试是软件的测试，但怎么对测试进行测试？就是用软件。为了对测试进行测试，必须破坏软件。”自由市场竞争
比特币期货平台BitMEX写过一篇名为《与比特币核心竞争》的文章，论述各种“比特币部署”的生态系统，这篇文章非常棒。当前，比特币的“兼容部署”有十几种，甚至还有更多的“竞争网络”部署。这就是“开源”的自由：只要哪个人对比特币核心项目的做法有所不满，就可以建立自己的项目。他们可以从零开始，也可以选择去分叉Core软件。在我写作本文时，96%的比特币节点是运行BitcoinCore软件的。为什么会是这样？倘若某人切换到另一种软件部署只需要极小的努力，那么比特币核心为什么又会在节点网络中处于类似垄断的状态？毕竟，很多其他部署，所提供的RPCAPI，都与比特币核心兼容，或者起码也跟比特币核心高度相似。
我相信，这是因为BitcoinCore成为了开发的焦点。Core拥有数量级更多的开发人才和开发时间的支持，这意味着BitcoinCore项目的代码往往是性能最高、最安全和最稳健的。在有限的资金下，节点运营商只想运行最好的软件，不想运行质量第二的软件。此外，考虑到BitcoinCore是一种共识软件，比特币协议不具有并且也不能具有正式的规范，所以使用焦点实现会更为安全。因为假设你运行的是其他版本的软件，对于网络的大多数节点而言，你的节点可能就是一个bug。从这个意义上来讲，开发焦点的代码就成了现实中最接近规范的东西了。谁是比特币核心开发者？
那些不熟悉比特币核心开发过程的人，可能会从外部观察这个项目，认为“Core”是一个大一统的实体。大错特错！核心贡献者之间常有分歧，而且就算那些最多产的贡献者，也写了很多代码，从没有合并入核心项目。你看看“贡献者”的指导方针，就可能会注意到，这方针的原则宽松得很，最多也只能说成一种“大略的共识”。维护人员会考虑，某个补丁是否符合项目的一般原则，是否符合“纳入”的最低标准。维护人员会判断各位贡献者的一般共识。维护人员都是谁呢？他们是一些特殊的贡献者。他们已经通过较长时间的高质量的贡献，在项目内部构建了足够的社会资本。现有的维护人员团体，只要认为某个贡献者已经在某特定领域展示了能力、可靠性、动机，有资格当上维护人员，就会把“提交的访问权”授予这位贡献者的GitHub账户。“维护人员领导”的作用，是监管项目的一切方面，并负责协调各次代码发布。这几年来，“维护人员领导”的头衔自愿更替了几次：中本聪：2009/1/3-2011/2/23GavinAndresen：2011/2/23-2014/4/7WladimirvanderLaan：2014/4/7-现在比特币核心维护人员的职责，经常被人比作“看门人”，因为维护人员实际上并没有权力作出决定，反对贡献者或者用户的集体共识。不过，这一职责的任务却可能相当繁重，因为大生态系统会特别注意这一职责。比如，2017年，GregoryMaxwell就因为个人原因而辞去了维护人员的职务，很可能是因为公开辩论升级，面临的舆论压力太大了。Wladimir写了一篇有深意的帖子，说的就是担任维护人员压力多么大，还说了为什么应该取消Gavin的提交权限，这帖子让很多人很不高兴。还有一个类似的情况：GitHub组织曾经开除了JeffGarzik，Jeff和其他人都非常恼火。但是，Jeff的错误在于，他整整两年没有为核心作出贡献了。组织再继续让Jeff的GitHub账户拥有代码仓库的写入权限，对项目也没有好处了，反而凭空增加了安全风险，也违反了“最小特权原则”。这原则，Wladimir在帖子里专门提到了。还有其他人可能会观察Core，认为Core是一个技术官僚群体，或是象牙塔，很难让新的参与者加入进来。然而，只要你跟那些贡献者真正交流过，就会发现不是这样。这几年确实只有少数几个人拥有提交权限，但却有数百名开发者已经作出了贡献。我自己也作了几个小贡献，虽然我不自认为是“核心开发者”，从技术上却算是一名核心开发者。谁也不能不让你作出贡献！
最难以让人们理解的，似乎是这样一个问题：比特币开发的关注点，并不仅仅是由比特币核心GitHub账户定义的那个结构。确实，比特币核心是有一种结构的，但项目本身却不受任何参与者控制，甚至不受那些对GitHub代码仓库有高级特权的人控制。从技术上说，确实有可能让一群维护人员发动“政变”，黑进GitHub代码仓库，审查那些异议开发者，甚至还能保持“比特币核心”这个品牌名称；但结果就会是，比特币核心不再成为开发关注点了。这种政变万一真的出现了，那些不同意维护人员的开发者，就会直接让代码分叉，把自己的工作换到另一个代码仓库，换到比特币核心维护人员没有管理权限的地方。就算不是真正的“政变”，如果核心真的发生了有争议的变化，还是会有一些开发者将软件分叉，除掉那个有争议的变化，然后对用户发布。历史上，AmaurySechet曾经让比特币核心分叉，在功能上除掉了“隔离见证”，创造了BitcoinABC。你可以认为，当时发生的就是这种情况。另外，如果某些人提议作出某些变化，而核心否决了这些提议的变化，开发者也可以将核心分叉，加上这些变化。历史上这种事情发生了很多次，例如：MikeHearn将核心分叉，创造了BitcoinXTAndrewStone将核心分叉，创造了BitcoinUnlimitedJeffGarzik将核心分叉，创造了BTC1将代码分叉容易，可是改变比特币开发的焦点就难了。你必须说服贡献者：“你们的时间最好能花在我这个不一样的项目上！”
你也很难说服许多人，让他们相信，用户们并不盲目跟从BitcoinCoire作出的各种变化。这可能是一个自我强化的信念，因为如果用户不通过保持对选项的了解来参与共识的过程，他们就会把部分权力让给开发人员。不过，2017年，用户的权力已经通过“用户激活软分叉”运动得到了行使。当时，有个比特币的匿名开发者，用假名“shaolinfry”提出BIP148，强迫矿工在8月1日前后要出现“区块高度”时激活“隔离见证”功能。但是，BIP148的争议实在太大，比特币核心无法采用。于是，shaolinfry将核心分叉，发行了软件BitcoinUASF。这一软件部署获得了非凡的“牵引力”，而且似乎创造了足够的压力，能让矿工采用BIP91，从而在BIP148截止日期之前激活分叉。我个人认为，最好的BitcoinCore贡献者，是那些践行了极端所有权的人。举个典型例子：下图中这个特定的共识bug所在的代码，虽然并不是贡献者JohnNewbery自己写出来的，但他认为自己没有认真检查，而让这bug代码合并了；事后在写测试案例的时候，也没有查出来，所以自己要承担责任。
我们都是中本聪。为BitcoinCore做出贡献
虽然有足够的资源可以帮助那些有抱负的开发者，但是迈出第一步为Core做贡献，依然可能让人望而生畏。此处可以找到贡献的指导方针：https://bitcoincore.org/en/faq/contributing-code/但我更推荐从JimmySong写的简易入门开始：https://medium.com/m/global-identity?redirectUrl=https%3A%2F%2Fbitcointechtalk.com%2Fa-gentle-introduction-to-bitcoin-core-development-fdc95eaee6b8此外，核心开发者EricLombrozo也写了一篇文章，方便人们理解核心代码仓库里的种种变化：https://medium.com/@elombrozo/the-bitcoin-core-merge-process-74687a09d81d还有一个特殊案例可能对你有用：在撰写本文时，为了审计GitHub提交历史的完整性，我在我的机器上运行verify-commit.py脚本；这个运行过程，正好遇到了一些困难。为了不让以后的开发者遇到同样难题，我开启了一个“pull请求”用来改进存档过程。为了防止未来的开发人员不得不处理这些问题，我打开了一个pull请求来改进文档。从PR历史中可以看出，4个不同的开发人员就如何改进我的pull请求提出了建议。这包括使用不同的wiki标记，简化的bash命令，以及可以在verify-commit.py脚本中使用的新参数。我同意所有的建议都是有道理的，所以我把它们合并到我的代码中，并推送了一个更新版的pull请求。此时，参与审查的开发人员承认，他们发现PR是可以接受的，维护人员MarcoFalke将其标记为包含在0.18版本中。几天过去了，开发人员没有异议，代码被维护人员SamuelDobson合并到了Core软件当中。谁在控制比特币？
多年来我反复说过，想要完全理解作为“体系”的比特币，几乎是不可能的。比特币协议的定义，就好比语言的定义一样。语言是人类自发产生的，对于词义的共识，是有机的、生活中的共识，而不是让词典决定意义。词典的作用是描述一种语言的客观现象，而不是给语言下定义；同样，比特币的部署，也是用代码描述比特币的语言。不可能强迫任何人同意某词典对某词的定义，也不可能强迫任何人同意某特定比特币部署里的代码。言语不受民主体制的管辖，比特币也不受民主体制的管辖。你可能会听说人们提到一些概念，如矿工、节点、开发者、用户投票等等；却没有这样的机制，可以促成任何种类的“多数人投票”，强迫少数异议人士接受那些自己反对的变化。比特币是一种无政府主义，没有统治者，但依然有着规矩。规矩由网络中每一个参与者定义，由每一个参与者强制执行。比特币协议本身的各种变化，一般通过“比特币改进提议”的流程实现。不过，哪怕这个提议，也只是一种推荐的操作方式，并不能强迫任何人遵守。只是一种相对规范的途径，想要通过同行评审，构建共识的办法来引导实现一种变化。我知道，要解释这一切很困难，要明白也很困难。但是，这就是比特币“抗脆弱性”的关键方面。如果有了“单点控制”，也就成了“单点故障”。如果那些有权有势的机构受到比特币带来的威胁，他们就会充分利用这一点对比特币进行攻击。最终，每一个节点运营商都会自我治理，方法就是确保网络中其他所有人都不会破坏自己认可的规矩。这种安全模型，就是比特币自下而上治理的基础。没有人控制比特币。也没有人控制比特币开发的焦点。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。