谁在控制比特币核心软件？开发者揭秘比特精灵设置

前言：关于Bitcoin Core软件，由于扩容之争，很多人认为它的发展是片面的，而核心开发者Jameson Lopp想借这篇文章来解释Bitcoin Core的运作，澄清比特币是没有控制者的，文中提到了很多不为人知的秘密。

以下为全文译文：

关于谁有能力将代码更改写入比特币核心库的问题经常被提出。 多年来，各方都将此称为比特币协议的“控制中心”，但我认为问题本身是一种源于专制观点的转移注意力的谬论，这种模式不适用于比特币。 对于外行人来说，其中的原因当然并不明显，因此本文的目的是解释比特币核心是如何工作的，以及在更高层次上解释比特币协议是如何演变的。

比特币核心的历史

Bitcoin Core 是比特币协议发展的重点，它不是命令和控制点。 如果它因任何原因不复存在，将会出现一个新的焦点，基于一个技术交流平台（目前是 GitHub 存储库），这是出于方便而不是定义/项目完整性的问题。 事实上，我们已经看到比特币的发展经历了平台转移，甚至更名！

2009 年初，比特币项目的源代码只是托管在 SourceForge 上的一个 .rar 文件。 早期的开发人员实际上会通过电子邮件与中本聪交换代码补丁。 2009 年 10 月 30 日，Sirius (Martti Malmi) 在 SourceForge 上为比特币项目创建了一个 subversion 存储库； 2011年，比特币项目从SourceForge迁移到GitHub； 2014年，比特币项目更名为Bitcoin Core； 不要相信任何人

虽然这个组织存在一些能够将代码合并到 master 分支的 GitHub“维护者”帐户，但这更多的是一种清洁功能，而不是一个强大的位置。 如果有人可以将代码合并到 master 分支中，比特币代码库将很快变成“厨房里有太多厨师”的场景。 Bitcoin Core 遵循最小特权原则，这意味着授予个人的任何权力如果被滥用，很容易被颠覆。

从对抗的角度来看，GitHub 是不值得信任的。 未经维护者同意，任何数量的 GitHub 员工都可以使用他们的管理权限将代码注入比特币存储库。 但 GitHub 攻击者也不太可能破坏比特币核心维护者的 PGP 密钥。

Bitcoin Core 没有基于 GitHub 帐户之外的代码完整性，而是有一个持续集成系统，该系统针对每次合并提交都必须签署的受信任 PGP 密钥执行检查。 虽然这些密钥与已知身份相关联，但假设情况总是如此仍然不安全，密钥可能会被泄露，除非原始密钥所有者通知其他维护者，否则我们不会知道。 因此，提交密钥也不能提供完美的安全性，它们只会让攻击者更难注入任意代码。

比特币王国的钥匙

在撰写本文时，这些是受信任的 PGP 指纹：

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

这些key分别对应以下5个人：

弗拉基米尔·J·范德兰·彼得·乌耶

Jonas Schnelli Marco Falke 塞缪尔多布森

这是否意味着我们信任这五个人？ 不完全的。 钥匙不是身份证明比特币精灵安全吗，这些钥匙可能会落入坏人之手。 如果运行 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 做贡献时没有看门人或入学考试。 如果拉取请求确实有用并且没有合理的反对意见，那么维护者会将其合并到核心软件中。 核心维护者设置此预推送挂钩以确保他们不会将未签名的提交推送到存储库中。 合并提交可以选择通过 OpenTimestamps 安全地加上时间戳； Travis 持续集成系统定期运行此脚本以检查 git 树（历史）完整性并验证主分支中的所有提交都是使用受信任的 PGP 密钥签名之一进行的； 任何想要运行此脚本来验证可追溯到 2015 年 12 月的所有合并提交的 PGP 签名的人。我在写这篇文章时运行了它，在我的笔记本电脑上，这个过程花了 25 分钟。 发布安全 Gitian 确定性构建系统由多个开发人员独立运行比特币精灵安全吗，目标是创建相同的二进制文件。 如果有人设法创建了一个与其他开发人员的构建不匹配的构建，则表明引入了非确定性，因此最终发布不会发生。 如果存在不确定性，开发人员会找出问题所在，修复它，然后构建另一个候选发布版本。 一旦确定性构建成功，开发人员就会对生成的二进制文件进行签名，从而保证二进制文件和工具链未被篡改并使用相同的源代码。 这种方法消除了构建和分发过程中的单点故障，任何具有技术技能的人都可以运行自己的构建系统，如这里所述。 一旦 Gitian 构建完成并由构建者签名，Bitcoin Core 维护者将对包含每个构建的 SHA256 哈希的消息进行 PGP 签名。 如果您决定运行预构建的二进制文件，您可以在下载后检查其哈希值，并使用该哈希值来验证签名版本消息的真实性。 可以在此处找到这样做的说明。 以上所有内容都是开源的，任何有技能和愿望的人都可以查看。 最后，即使完成了上述所有质量和完整性检查，提交给比特币核心并最终发布的代码也不会被任何中心化组织部署到节点网络。 相反，每个节点运营商必须有意识地决定更新他们运行的代码。 Bitcoin Core 特意没有自动更新功能，因此用户可以自行决定需要运行什么版本的代码。

尽管 Bitcoin Core 项目实施了上述所有技术安全措施，但它们并不完美，理论上任何一项都可能遭到破坏。 Bitcoin Core 代码完整性的最后一道防线与任何其他开源项目一样，就是开发者需要时刻保持警惕，审查 Bitcoin Core 代码的眼睛越多，越不可能恶意代码或错误代码将进入发布客户端。

代码覆盖率

Bitcoin Core 有很多测试代码，有针对每个 PR 运行的集成测试套件，以及每晚在 master 上运行的扩展测试套件。

您可以通过以下方式自行检查测试的代码覆盖率：

克隆比特币核心 GitHub 存储库； 安装从源代码构建所需的依赖项； 运行这些命令； 在 ./total_coverage/index.html 查看报告；

或者，您可以在此处查看由 Marco Falke 主持的覆盖率报告。

拥有如此高的测试覆盖率意味着代码可以按预期工作的更大确定性。

当涉及到共识关键软件时，测试是一件大事。 并且对于特别复杂的变更，开发人员有时会进行艰苦的变异测试，即他们通过故意破坏代码并查看测试是否如预期那样失败来进行测试。 Greg Maxwell 在讨论 0.15 版本时对这个过程给出了一些见解：

“测试就是对软件的测试，那么什么是测试对测试？要对测试进行测试，你必须打破软件。” - 格雷格麦克斯韦

自由市场竞争

BitMEX 写了一篇关于比特币实施生态系统的优秀文章。 目前有十几种不同的比特币兼容实现，甚至更多的“竞争网络”实现。 这就是开源的自由。 任何对比特币核心项目不满意的人都可以自由运行自己的软件。 他们可以从头开始，也可以选择分叉核心软件。

在撰写本文时，96% 的比特币节点运行比特币核心软件。 为什么会这样出来？ 如果切换到另一种软件实现只需要最少的努力，比特币核心怎么能在节点网络上近乎垄断？ 毕竟，许多其他实现提供了与 Bitcoin Core 兼容或至少非常相似的 RPC API。

我相信这是因为 Bitcoin Core 是开发的重点，得到了数量级更多的开发人才和开发时间的支持，这意味着 Bitcoin Core 项目的代码往往是性能最好和最安全的。 在资金管理方面，节点运营商不想运行次优软件。 此外，鉴于这是共识软件，而比特币协议没有正式规范，使用焦点实现更安全（因为假设你正在运行其他版本的软件，对于网络上的大多数节点，你的节点可能只是一个错误）。 从这个意义上说，以开发为中心的代码是最接近现有规范的东西。

谁是核心开发人员？

不熟悉 Bitcoin Core 开发过程的人可能会从外部看待该项目，并将 Core 视为一个整体。 这远非如此！ Core 贡献者之间经常存在分歧，即使是最多产的贡献者也会编写大量从未合并到项目中的代码。 如果您阅读过关于贡献的指南，您可能已经注意到它们相当松散，最好将这个过程描述为“粗略的共识”。

“维护者会考虑补丁是否符合项目的一般原则；是否满足包含的最低标准；并会判断贡献者的普遍共识。”

谁是比特币核心的维护者？ 他们是那些通过在一段时间内提供高质量的贡献而在项目中积累了足够社会资本的贡献者。 当现有的维护者组认为贡献者已经展示了能力、可靠性和积极性时，他们可能会授予对该贡献者的 GitHub 帐户的提交访问权限。 而首席维护者角色是监督项目所有方面并负责协调发布的人。 多年来，共有三位主要维护者，他们是：

Satoshi Nakamoto 2009.1.3 - 2011.2.23 Gavin Andresen 2011.2.23 - 2014.4.7 Wladimir van der Laan 2014.4.7 至今

担任比特币核心维护者通常被称为看门人，因为维护者实际上没有权力做出违背贡献者或用户共识的决定。 然而，由于整个生态系统的额外关注，这个角色的压力可能是巨大的。 例如，Gregory Maxwell 在 2017 年出于个人原因放弃了他的维护者角色，这很可能是因为他在扩容辩论中遇到的公众压力。

Wladimir 写了一篇关于作为 Core 维护者的压力以及为什么应该删除 Gavin 的提交权限的文章，这让很多人感到不安。

同样，Jeff Garzik 和其他人在他的维护者特权被取消时感到不舒服，即使 Garzik 已经两年没有为 Core 做出贡献。 将他的 GitHub 帐户维护权限授予 core 对项目没有任何好处，它只会产生安全风险并违反 Wladimir 在他的帖子中提到的最小特权原则。

其他人可能看到了 Core 正在发生的一些事情，并认为它是一个技术官僚组织或象牙塔，使得新进入者很难加入。 但是，如果您与贡献者交谈，则情况并非如此。 虽然在过去几年中只有十几个人拥有提交权限，但数百名开发人员已经为比特币做出了贡献。 我自己也做了一些小贡献，当然我不认为自己是“核心开发者”，但我是一个核心软件开发者。 没有人能阻止你为比特币做贡献！

虽然 Bitcoin Core 有一些结构（它使用集中的通信渠道来协调），但项目本身不受任何参与者（即使是那些提升 GitHub 存储库权限的人）的控制。 即使维护者团体政变可以在技术上劫持 GitHub 存储库，审查持不同意见的开发者，甚至可能争夺“Bitcoin Core”品牌，结果将是 Bitcoin Core 不再是开发的重点。 不同意维护者所做工作的开发人员可以简单地分叉代码并将他们的工作转移到不同的存储库，而比特币核心维护者没有管理权限。

即使没有发生“政变”，如果有争议的更改确实以某种方式进入核心软件，一些开发人员也会分叉软件，删除有争议的更改，并将其提供给用户。 你可能会争辩说，这正是 Amaury Sechet 分叉比特币核心、然后删除隔离见证 (SW) 功能并创建比特币 ABC 时发生的事情。 或者，如果 Core 拒绝了某人想要的提议更改，开发人员可以分叉并添加这些更改。 这种情况发生过很多次，例如：

Mike Hearn 分叉 Core 并创建了 Bitcoin XT； Andrew Stone 分叉 Core 并创建了 Bitcoin Unlimited； Jeff Garzik 分叉了 Core 并创建了 BTC1；

分叉代码很容易，但转移比特币开发的重心却非常困难。 您必须说服贡献者将他们的时间花在不同的项目上。

你也很难说服很多没有盲目追随比特币核心变化的用户，这可能是一种自我强化的信念，因为如果用户不通过了解选项来参与共识过程，他们将部分权力让给了 Developer。 然而，在 2017 年的 UASF（User Activated Soft Fork）运动中，用户的权力得到了行使。 匿名比特币开发者 shaolinfry 提出了 BIP 148，这将强制矿工为 8 月 1 日左右创建的区块激活隔离见证。然而，BIP 148 被证明争议太大，无法被 Bitcoin Core 采用，因此 shaolinfry 分叉了 Core 软件并创建了“比特币 UASF”软件，一种软件实施获得了非凡的牵引力，并且似乎产生了足够的压力来说服矿工采用 BIP 91（在 BIP 148 截止日期之前）来激活分叉。

在我看来，最好的比特币核心贡献者是那些实践极端所有权的人。 恰当的例子：即使 John Newbery 没有编写包含这个特定共识错误的代码，他也责备自己没有仔细审查它。

我们都是中本聪。

为比特币核心做贡献

虽然有很多资源可以帮助有抱负的开发人员，但一开始为 Core 做贡献可能会让人感到害怕。 贡献指南可以在这里找到：

当然，你可能还想从几米宋的介绍开始。

Core 开发者 Eric Lombrozo 也写了一篇关于了解如何在 Core 存储库中进行更改的文章：

@elombrozo/the-bitcoin-core-merge-process-74687a09d81d

在撰写本文时，我无法在我的机器上运行 verify-commit.py 脚本来审核 GitHub 提交历史记录的完整性，具体示例可能会有用。 为了防止未来的开发人员不得不处理这些问题，我已经打开了一个拉取请求来改进文档。 从 PR 历史可以看出，4 位不同的开发人员对如何改进我的拉取请求提出了建议。 这包括使用不同的 wiki 标记、简化的 bash 命令以及可在 verify-commit.py 脚本中使用的新参数。 我同意所有的建议都是有道理的，所以我将它们合并到我的代码中并推送了一个更新的拉取请求。 此时，参与审查的开发人员承认他们发现 PR 可以接受，维护者 Marco Falke 将其标记为包含在 0.18 版本中。 几天过去了，开发人员没有提出异议，代码被维护者 Samuel Dobson 合并到核心软件中。

谁在控制比特币？

正如我多年来广泛争论的那样，完全理解比特币作为一个系统几乎是不可能的。 比特币的定义就像语言的定义。 语言是自发产生的，对词义的共识是有机的，不是由字典口述的。 正如字典描述语言现象而不是定义它一样，比特币的实现在代码中描述了比特币的语言。 没有人被迫同意字典中给定单词的定义，也没有人被迫通过运行比特币来同意给定比特币实现中的代码。

语言不受民主支配，比特币也不受民主支配，虽然你可能会听到人们将矿工、节点、开发人员或用户称为“投票”，但没有任何形式的多数投票可以迫使少数持不同政见者的机制接受他们的不同意见。 同意变更。 比特币没有统治者，但并非没有规则，其规则由网络上的各种参与者定义和执行。

虽然对比特币协议本身的更改通常是通过比特币改进提案流程进行的，但即使这是推荐的最佳实践，也没有人被迫遵循它。 这只是一种更正式的方式，试图通过同行评审和建立共识的过程来引导变革。

虽然这很难解释和理解，但如果存在单点控制，这也将是比特币抗脆弱性的一个关键方面，同时也是单点故障，将受到比特币的威胁。 实体使用。 最终，每个节点运营商通过确保网络上没有其他人违反他们同意的规则来进行自我管理。 这种安全模型是比特币自下而上治理的基础。

没有人控制比特币。

也没有人控制比特币开发的重点。

最后，感谢 John Newbery。