Joannes Vermorel's blog

 Author Image

Software typically involves people

     

© 2022 Joannes Vermorel.

以经验来谈BCHN

Sep 4, 2020
bitcoin

作者： Joannes Vermorel （Lokad创始人，Corps Des Mines工程师；业余时间兼职做技术审计；点击查看作者的更多资料）

发表于2020年8月24日

原文链接

比特币1生态系统中再一次发生了匪夷所思的事：该系统似乎仍然无法判定在进行一个高技术含量的计划时，技术能力重要与否。几个月前，一个由多年来参与开发比特币软件的老前辈（他们各自的主要贡献是Bitcoin Unlimited和Electron Cash）组成的团队2，为一个名为Bitcoin Cash Node（BCHN）的项目走到了一起。这支团队似乎在一些社交媒体上越来越受欢迎；一些人信任这支团队，给予了他们不菲的资助3。

就创新而言，资金可以解决许多问题。但是，资金无法补足技术能力。更糟糕的是，在软件领域，除了更换团队成员外，没有其它办法能够解决技术能力不足的问题。仅仅有能力是不足以成功的；但反过来说，不管有多少投资者在过程中被愚弄，技术上的无能将无一例外地走向失败。

以经验性依据来看BCHN成员最近和过去的代码贡献，可以看出这种热情是错位的。关于这支团队是否能维护几个月前他们通过分叉所得的代码库4，人们还存有质疑。任何希望这个团队能够提供最先进的软件基础设施，以供BCH在众多竞争中胜出的想法都是痴人说梦。

由于BCHN团队做开源项目，因此可以通过直接审查其成员的公开代码来评估其技术水平。有三个代码库值得关注：BCHN、Bitcoin Unlimited（BU）和 Electron Cash。通过对这些代码库的审查，可以得到以下结论：

基于这些见解，BCHN似乎已不太可能提供类似于ABC路线图这样的东西；更不用提BCHN带领BCH超越众多竞争对手的可能性了。

对BCHN的洞察

截止到目前，BCHN的贡献还很少且不起眼。事实上，这个项目一开始就是作为Bitcoin ABC（ABC）代码库的分叉而存在的，至今还没有任何显著的贡献使这个代码库明显区别于ABC的代码库。要提BCHN自分叉以来最显著的变化，还是向后移植了ABC自己作出的变动。

然而，BU的许多不良操作（在下一节会有更多的介绍），已经被BCHN继承了。让我们来斟酌分别来自于ABC和BCHN的向后移植操作。

ABC提交的向后移植提供了有意义的标题，其传达了工作的意图;明确指出了向后移植的源头，例如Bitcoin Core（Core）;（代码）还指明了这个向后移植是三个序列中的第一个提交，反映了逻辑清晰的向后移植单元。最后，提交的所有权被正确地分配给原始的Core贡献者。

基本很难理解BCHN的向后移植提交。提交的标题只包含了向后移植的代码编号，因此无法提供向后移植的原因或内容的具体线索；没有任何链接指向原始贡献；代码归属于Core，却被错误地分配给了 BCHN 成员；关于提交的关键细节只能在 BCHN 的 ticket 管理系统中找到。

虽然提到的最后一点对读者来说可能很玄乎，但它概述了BCHN工作流程中的一个重要问题：BCHN的代码库名义上是开源的；但他们的工作流程，对希望从他们的贡献中获益的其他团队是很不利的。由于对他们代码库的提交不是有逻辑的原子贡献，任何第三方都很难从BCHN中向后移植任何东西6。此外，不正确的作者归属也激化了有职业操守的团队间的摩擦7。讽刺的是，正是Core和ABC正确的软件实践，为BCHN提供了从他们那里向后移植工作的可能性；而反之则不成立。

BCHN代码库的第二个主要问题是，（参照BCHN管理下的代码提交）基本无法破译提交的历史。大部分的提交标题只包含神秘的代码编号，这让人难以理解到底发生了什么。这种做法不仅不利于对代码进行审计，也进一步阻碍了未来从BCHN进行向后移植的尝试。

上面列出的BCHN提交，绝不能被当做传闻而忽视掉；因为绝大多数BCHN对自己代码库的贡献都有类似的缺陷。

另一个典型的提交是BCHN项目负责人，于一个月前撰写的将 “master “分支合并到 “master “的提交。虽然这个提交本质上并不重要（它只是一些文档），但这个提交符合代码库的 “随机变化行为 “。提交的标题毫无意义。提交的评论是对提交内容的解读。提交时附上的ticket也过于神秘。

总的来说，BCHN团队短暂的提交历史已经几乎无法被破解。提交的标题毫无意义；提交的评论常常缺失，取而代之的是指向tickets8的链接。这种状况，与分别来自于ABC和Core的提交历史形成了鲜明的对比；对第三方而言，ABC和Core的提交历史更容易访问，而且它们可以独立存在，不会过分强调特定的ticket管理系统。

对Bitcoin Unlimited的洞察

BCHN的六位贡献者中有四位，是BU过去几年的重要贡献者。BCHN项目基本上是BU项目的直接替代品。BU获得了相当于几百万美元的资金9，然而经过5年的软件开发努力：

已经讨论过BU “牛仔 “的开发风格。然而，这种闹腾还是一如既往的强势。今年7月底的提交，试图"修复锁定问题”（sic）。然而，没有测试、没有审查、没有评论、没有调查为什么这个问题最初发生的原因，没有评估对社区的影响，也没有给出为什么修复工作有用的理由等等。

点睛之笔：原本很容易解决的问题，却让这次提交破坏了原始代码的缩进。即使是一个半路出家的软件工程师也应该听说过linters（40年前发明的linters就是为了消除这类普通的问题）。但显然BU团队不曾听说过，或者更有可能的是，他们对此毫不在意。

多年来，许多参与者一直不遗余力地宣传BU。几乎从每一个实际角度（例如：道义上、技术上和政治上等）来看，BU都被呈现为比ABC更优秀的存在。然而，现实并不遵从于众人的疯狂。今年年初，几位BU成员和他们的长期支持者终于清醒地意识到，BU的代码库基本上已经破损到无法修复的地步。

因此，BU的代码库被完全抛弃，BCHN转而“干净“的分叉了ABC代码库。但是，几乎没有理由不去质疑BCHN将走BU的老路：相同的贡献者在追求相同的目标，同时采用了相同的软件开发实践；他们将获得相同的软件成果。

对Electron Cash的洞察

Electron Cash(EC)代码库，为BCHN最终将交付的终极软件产品(如果有的话)提供了可靠的参考。事实上，最活跃的BCHN贡献者也恰好是最活跃的Electron Cash贡献者。还有两位BCHN的贡献者也恰好是EC的小贡献者。此外，EC所解决的问题与BCHN要解决的问题密切相关。因此，开发EC所需的软件技术与开发BCHN所需的软件技术大致相同。

EC尤为有意思的原因在于，不同于BCHN代码库仍然是第三方产品（代码来自Core和ABC），EC团队当下真正掌控着EC代码库10。因此，可以说这个代码库–在全球范围内–反映了BCHN团队独当一面时的软件编程技术。事实上，到目前为止，对BCHN和BU的分析仅限于提交。因此责怪BCHN代码库中的Merkle tree问题是不合理的，因为他们是从中本聪那里继承了这一问题。

从很多层面来看，EC代码库都是一场恐怖的表演，甚至要总结出这个项目的问题所在都很具挑战性。

Main_window.py文件突显了以下这些问题（甚至还有更多问题没有被指出）：

基于这些观察，EC似乎是有史以来记录的软件反面模式中，占据相当大比例的一个鲜活例子。要弄清楚EC代码库中其他反面模式出现的情况，就留给细心的、非常有耐心的读者去做。

几天前，EC团队基于提出的路线图完成了一轮融资。EC团队似乎丝毫没有意识到，他们的代码库背负着大量的技术债。清算这笔债务应该优先于其他一切工作。建议的路线图和迫切需要的工作之间完全脱节。

在这一点上，为EC增加更多的功能是不负责任的13。唯一合理的做法是对EC的开发实践进行彻底的整修，然后对整个代码库进行细致的渐进式重写14。

关于freetrader的领导力

BCHN团队由 freetrader 领导，他是一位匿名贡献者；在创建BCH分叉时，他是Bitcoin ABC的一员。这种参与似乎赋予了他 “BCH联合创始人 “的光环。

然而，仔细审查freetrader在6个月内的79次提交，就知道他技术上15是ABC一份子讲的是另一回事。这些提交的由普通的和次要的内容主导：外观上的缺陷，细小的测试修复，细小的BCH与BTC变动，等等。这个提交流反映了初级开发者，或实习生在前辈的密切指导下进行基础但有用的工作。

如果我们看看BCHN代码库中freetrader提交的部分，就会看到更多类似的情况，只是监督更少了。一个高级软件工程师，非常不可能让实习生把9个名为Merge branch的提交推到“master”中，因为这么做非常无厘头。

freetrader的其他代码贡献，明显缺乏雄心壮志，比如重构内存池，UTXO，或者疯狂锁定老Satoshi客户端。

最后，评判一个领导者还得看他给项目指出的方向。在这一点上，BCHN的路线图相当壮观（以下是官网原文的引注）：

“建立一个听取反馈意见，并提供可量化的改进的专业挖矿节点。就DAA、0确认和脚本的改进，提供经充分研究的共识规则改进建议。以身作则，通过规范驱动的开发，实现更大的挖矿节点多样性，以提高BCH的抗审查能力。”

这种散文符合企业最喜闻乐见的口号：用模糊、普世认同的语言粉饰组织本身的定位，譬如“专业”、“充分研究”、“以身作则”。

结论

BCHN背后的贡献者–无论是个人还是集体–在数年内为几百条的公共软件贡献中，都显示出他们缺乏软件工程技能；而且在很大程度上，他们也缺乏获取这些技能的兴趣。事实上，随着时间的推移，BCHN贡献者们所做的工作并没有明显的改进。他们今天的软件实践与三年前一样糟糕。

几十年来，市场对软件工程师的需求量一直很大。然而，人们非常怀疑BCHN的任一贡献者是否会被一家受人尊敬的软件公司聘用（即使是初级岗位）。考虑到BCH的各种项目获得的资助，显著低于软件工程师的一般市场水平；有人不禁要问，这些参与者是否纯粹因为缺乏更好的职业前景而留在BCH项目中。

预测一个软件企业的成功，充其量是一种幸运的尝试。然而，如果有具体的观察，几乎可以预测到（项目）必然的失败。就BCHN而言，充分的经验证据表明—-几乎可以肯定—-无论提供多少资金，他们都不会给BCH利益相关者带来任何价值。

  1. 在本文中，比特币总是指比特币现金。 ↩︎

  2. BCHN团队由freetrader（化名）领导。其他团队成员包括Calin Culianu、 imaginaryusername（化名）、Dagur Val、BigBlockIfTrue（化名）和Andrea Suisani。BCHN代码库的其他贡献者参与度太低，因此将其被视为团队成员并无意义。 ↩︎

  3. BCHN联合创始人Calin Culianu宣布获得价值70万美元的融资。于2020年8月21日抓取网页快照。 ↩︎

  4. BCHN项目是在2020年2月，通过分叉比特币ABC代码库而建立的。 ↩︎

  5. 由于男性在 “密码货币 “软件工程师中占据了主导地位，因此我假设freetrader是一名男性。用 “她/他/他们 “来代替 “他”，感觉就太乏味了。 ︎ ↩︎

  6. BCHN成立的前提是ABC道德败坏，不以 “社区 “的利益为重。︎ ↩︎

  7. 主流开源社区的主要精神之一是源代码的适当作者归属。这个行为准则并没有具体的强制执行，但是，违反这个准则的行为是非常不受欢迎的–就像现代社会中不讲究个人卫生一样。 ↩︎

  8. 在提交之前，通常双方会先讨论手头的事情。这种讨论通常在基于网络的ticket管理系统中，以这样或那样的形式进行。与提交（常常是持久的）不同的是，讨论通常被认为是短暂的。在ticket管理系统方面，BCHN使用GitLab，Core使用GitHub，ABC使用Phabricator。 ↩︎

  9. 早在2016年8月，BU就已经收到了相当于50万美元的BTC。考虑到之后BTC的大幅升值，我们有理由认为BU获得的资金超过500万美元。 ↩︎

  10. EC最初是从一个名为Electrum的项目中分叉出来的。然而，在11,000多次提交中，EC团队可以宣称4,000多次提交。自BCH成立以来，他们一直将这个项目作为自己的项目来运行。在他们最近的开发中，从原来的Electrum项目的向后移植工作不再显得重要。 ↩︎

  11. EC依赖于远程区块链索引器。钱包和索引器之间的互动可以说极其少。︎ ↩︎

  12. 参照这条评论# eval一般被视为不良操作。请小心使用！后面跟着对eval的call，没有给出为什么这个call是不良操作的理由。 ↩︎

  13. EC理应是一个让现实世界的人用来管理真实货币的钱包。当涉及到这一类软件时，有一个道德义务，就是不要把大众当做实验小白鼠。︎ ↩︎

  14. 考虑到EC代码库的糟糕状况，从头开始可能会更容易。有人可能会说，这样的努力不会给社区带来任何价值。唉，贝鲁特港务局同样不相信消除所有这些硝酸铵会给他们的社区带来任何好处。 ↩︎

  15. 79次提交分散到6个月，暗示着投入很少，即每周工作不超过1天。 ↩︎